On 01/20/19 17:13, Chapman Flack wrote: > On 01/20/19 12:48, Pavel Stehule wrote: >> regular Postgres' functions has evaluated all arguments before own >> execution. I think so this note is related much more to expressions used as >> defaults. > > Sure, but again, is there an example, or can one easily be constructed, > that shows the default expressions working in such a way?
To make my question more concrete, here is the current regression test query that uses an SQL expression for a default: SELECT xmltable.* FROM xmltest2, xmltable(('/d/r/' || lower(_path) || 'c') PASSING x COLUMNS a int PATH 'x' DEFAULT ascii(_path) - 54); a ---- 11 12 13 14 (4 rows) Here is the same query desugared into a call of the PL/Java "xmltable": SELECT xmltable.* FROM xmltest2, LATERAL (SELECT x AS ".", ascii(_path) - 54 AS "A_DFT") AS p, "xmltable"(('/d/r/' || lower(_path) || 'c'), PASSING => p, COLUMNS => ARRAY[ 'let $a := x return xs:int(if (exists($a)) then $a else $A_DFT)' ] ) AS (a int); a ---- 11 12 13 14 (4 rows) So the PL/Java version works and produces the same results. And yet it certainly is a "regular PostgreSQL function" made with CREATE FUNCTION, no special treatment of arguments, all evaluated before entry in the usual way. So it appears that this example does not depend on any special treatment of the default_expression. Is there an example that can be constructed that would depend on the special treatment (in which case, the PL/Java implementation would be unable to produce the same result)? Regards, -Chap ... the xs:int(...) cast above is needed for now, just because the PL/Java implementation does not yet include the standard's algorithm to find the right cast automatically.