Subject: Re: PostgreSQL vs SQL/XML Standards
To: Pavel Stehule <pavel.stehule@gmail.com>
References: 
 <CAFj8pRDFQJMoKf-X+3p1ASwU02nnXfAXrg83Z3fHUBd-Gwuuxw@mail.gmail.com>
 <CAFj8pRB4NHismecE-SnezKz9OektP2H8t_684TbqQ4Ax3swZwQ@mail.gmail.com>
 <5C283168.8060001@anastigmatix.net>
 <CAFj8pRDRrxyr8=2PEFxP_eZCRqJMU4Jpj0whJM9pX0V4Q4EQvw@mail.gmail.com>
 <5C291741.9060506@anastigmatix.net>
 <CAFj8pRAmSUO1g1qnVgXmE=7bPULYjwDfyO5KDohsHMFesDenmA@mail.gmail.com>
 <5C297BB7.9070509@anastigmatix.net>
 <CAFj8pRCN=0k507nTfvNQuruHvomA4SiC6uGUXY5Gz0crxf-JAQ@mail.gmail.com>
 <5C3A7A90.3070207@anastigmatix.net>
 <CAFj8pRCSa0ekwc8AOUnEsLeJhWbq7_rOyFzruopfgBTaMpUWMA@mail.gmail.com>
 <5C43FAEB.2070000@anastigmatix.net>
 <CAFj8pRDLywawDY-dRsYdjF036iR_Y4em77X1DF7VodUqau_0Vg@mail.gmail.com>
 <5C4401BE.4080606@anastigmatix.net>
 <CAFj8pRCKwDGqP55RTykDq87DXuXStE+3Qy2Hf9Wxh_A-cUnwTw@mail.gmail.com>
 <5C449C71.7060903@anastigmatix.net>
 <CAFj8pRAabQWW13FS58fj1h6YxKsbhEaegRctf28TFeheWGn_3A@mail.gmail.com>
 <5C44B332.6070609@anastigmatix.net>
 <CAFj8pRAfjUJZX3so2TooQvag2C+5b1+sm4rzZuJkuO5UtDtkhg@mail.gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
From: Chapman Flack <chap@anastigmatix.net>
Message-ID: <5C44F26D.5010703@anastigmatix.net>
Date: Sun, 20 Jan 2019 17:13:01 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: 
 <CAFj8pRAfjUJZX3so2TooQvag2C+5b1+sm4rzZuJkuO5UtDtkhg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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