From: | Chapman Flack <chap(at)anastigmatix(dot)net> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: PostgreSQL vs SQL/XML Standards |
Date: | 2019-01-20 22:13:01 |
Message-ID: | 5C44F26D.5010703@anastigmatix.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
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.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2019-01-20 22:15:35 | Re: [PROPOSAL] Shared Ispell dictionaries |
Previous Message | David Rowley | 2019-01-20 21:57:18 | Re: Postgres doesn't remove useless join when using partial unique index |