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