Re: Typmod associated with multi-row VALUES constructs - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Typmod associated with multi-row VALUES constructs
Date
Msg-id CAFj8pRBSemyrTDrrowh-L3REZNLcqXu2zS9N9VHyz7Uvi5gb3A@mail.gmail.com
Whole thread Raw
In response to Re: Typmod associated with multi-row VALUES constructs  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List 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

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Back-patch use of unnamed POSIX semaphores for Linux?
Next
From: Stephen Frost
Date:
Subject: Re: pg_dump vs. TRANSFORMs