ne 20. 1. 2019 23:13 odesÃlatel Chapman Flack <c...@anastigmatix.net> napsal:
> On 01/20/19 12:48, Pavel Stehule wrote: > >> > >> Accordingly, I think the paragraph beginning "Unlike regular PostgreSQL > >> functions," is more likely to perplex readers than to enlighten them. > >> What it says about column_expression does not seem to lead to any useful > >> difference from the behavior if it were "just like regular PostgreSQL > >> functions". > > > > 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? > > I am not able to use a default expression to refer to an earlier > column in the column list of the xmltable call. > probably you can see the effect if you use some volatile function .. random(), nextval(), I think so notice in documentation was not a motivation to use it. It was explanation of implementation and warnings against side effect. > > I am able to use a default expression to refer to a column of an earlier > FROM item in the enclosing SELECT. But such a query ends up having LATERAL > form (whether or not the word LATERAL is used), and re-executes xmltable > whenever the referenced column value changes. In that case, whether the > default argument is evaluated at function entry or later doesn't seem > to matter: the function is re-executed, so evaluating the new default > at the time of entry is sufficient. > it has sense only for volatile functions. it was not often. On second hand deferred evaluation shoul not be a problem, and more, it is evaluated only when it is necessary, what is more sensible for me. > So, I have still not been able to construct a query that requires the > deferred evaluation behavior. But perhaps there is a way I haven't > thought of. > > Regards, > -Chap >
