Re: patch: function xmltable
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Pavel Stehule <pavel.stehule@gmail.com>,
Craig Ringer <craig@2ndquadrant.com>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2016-11-21T20:16:15Z
Lists: pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes: > Something I just noticed is that transformTableExpr takes a TableExpr > node and returns another TableExpr node. That's unlike what we do in > other places, where the node returned is of a different type than the > input node. I'm not real clear what happens if you try to re-transform > a node that was already transformed, but it seems worth thinking about. We're not 100% consistent on that --- there are cases such as RowExpr and CaseExpr where the same struct type is used for pre-parse-analysis and post-parse-analysis nodes. I think it's okay as long as the information content isn't markedly different, ie the transformation just consists of transforming all the sub-nodes. Being able to behave sanely on a re-transformation used to be an issue, but we no longer expect transformExpr to support that. regards, tom lane
Commits
-
Support XMLTABLE query expression
- fcec6caafa23 10.0 landed
-
Create <sect3> in the functions-xml section
- 4461a9bfd1ac 10.0 landed
-
Improve handling of "UPDATE ... SET (column_list) = row_constructor".
- 906bfcad7ba7 10.0 cited
-
Add xmlexists function
- 641459f26954 9.1.0 cited