Re: Are SQL-language function lock ordering deadlocks solved in PostgreSQL 18?

It sure seems like the intent of the change was to modify exactly that behavior. 

If you look at the major built-in sql-esque languages, sql(old), sql(new), PSM (new standard syntax) and pl/pgsql, I guess psm style and pure SQL might be overlapped with PSM style functions, especially if PSM functions can be inlined (I haven't looked yet)-- inlining of functions such as 'SELECT $1 + $2' being the only reason I write sql functions these days.   I have always found the strict compile time checking to be highly obnoxious except in the immutable/inlinable cases that come up now and then. 

Plan caching is not so important IMO, since execution time tends to greatly exceed plan time in my experience and the real performance bugaboo is bad, not uncached plans.   FIxing bad plans typically involves dipping into the pl/pgsql toolbox, using variable temp tables, planner directives, and other forbidden tools in PSM.  In simple terms, I also used to restrict server side coding  views and pure sql functions for abstraction, but have long since given up, and mainly write procedures :-).

I really wish PSM functions could do what pl/pgsql functions do, since I like the creation syntax vs the 'string is body of code',but, alas.

merlin