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.