Re: Typmod associated with multi-row VALUES constructs
Pavel Stehule <pavel.stehule@gmail.com>
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>, David G Johnston <david.g.johnston@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2016-12-08T13:53:19Z
Lists: pgsql-hackers
2016-12-08 14:03 GMT+01:00 Alvaro Herrera <alvherre@2ndquadrant.com>: > Tom Lane wrote: > > Alvaro Herrera <alvherre@2ndquadrant.com> writes: > > > Tom Lane wrote: > > >> In HEAD, we could change the RTE data structure so that > > >> transformValuesClause could save the typmod information in the RTE, > > >> keeping the lookups cheap. > > > > > Hmm, I think this would be useful for the XMLTABLE patch too. I talked > > > a bit about it at > > > https://www.postgresql.org/message-id/20161122204730. > dgipy6gxi25j4e6a@alvherre.pgsql > > > > I dunno. If your example there is correct that XMLTABLE can be called as > > a plain function in a SELECT list, then I doubt that we want to tie > > anything about it to the RTE data structure. If anything, the case where > > it appears in FROM seems to need to be treated as a generic RTE_FUNCTION > > case. > > Well, XMLTABLE is specified by the standard to be part of <table primary>, > which it turn is part of <table reference>. I can't immediately tell > whether it allows XMLTABLE to be called like a regular function. The > current patch allows it, but maybe that's not right, and it's probably > not that useful anyway. > It looks like function, and we support on both sides, so I implemented both. Probably, there is only 10 rows more related to this feature. Using this function in target list is not critical feature - now with LATERAL JOIN we can live without it. It is just some few steps forward to our user. Again - implementation of this feature is probably few lines only. > > > I've been trying to avoid getting involved in the XMLTABLE patch, mainly > > because I know zip about XML, but maybe I need to take a look. > > I think it'd be productive that you did so. The XML part of it is > reasonably well isolated, so you could give your opinion on the core > parser / executor parts without looking at the XML part. > The critical part has zero relation to XML. All is some game with tupledesc. Regards Pavel > > -- > Álvaro Herrera https://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
Commits
-
Fix reporting of column typmods for multi-row VALUES constructs.
- cf22c8cb8900 9.6.2 landed
- c7a62135acfb 9.4.11 landed
- 6a493adda745 9.5.6 landed
- 2afe282a3732 9.3.16 landed
- 082d1fb9e4ec 9.2.20 landed
- 0b78106cd465 10.0 landed