Re: PostgreSQL vs SQL/XML Standards
Pavel Stehule <pavel.stehule@gmail.com>
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Chapman Flack <chap@anastigmatix.net>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-01-21T06:33:52Z
Lists: pgsql-hackers
ne 20. 1. 2019 23:13 odesílatel Chapman Flack <chap@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 >
Commits
-
Improve documentation about our XML functionality
- 728c49779ba8 11.6 landed
- 603a28b44973 10.11 landed
-
Improve documentation about our XML functionality.
- 12d46ac392d0 12.0 landed
-
Add volatile qualifier missed in commit 2e616dee9.
- b2b819019f44 12.0 landed
-
Fix crash with old libxml2
- 2e616dee9e60 12.0 landed
-
Fix minor deficiencies in XMLTABLE, xpath(), xmlexists()
- 251cf2e27bec 12.0 cited
-
Fix the BY {REF,VALUE} clause of XMLEXISTS/XMLTABLE
- eaaa5986ad03 12.0 landed
-
doc: Update README.links
- b060e6c1f5b4 12.0 landed
-
XPath fixes:
- 3963574d1338 8.3.0 cited