Re: delta relations in AFTER triggers - Mailing list pgsql-hackers

From Robert Haas
Subject Re: delta relations in AFTER triggers
Date
Msg-id CA+TgmoYH1TYRjHy7HrJ5RdX_kPpfh150KXJA3Gqp6BXBNVFOgQ@mail.gmail.com
Whole thread Raw
In response to Re: delta relations in AFTER triggers  (Kevin Grittner <kgrittn@gmail.com>)
Responses Re: delta relations in AFTER triggers  (Kevin Grittner <kgrittn@gmail.com>)
List pgsql-hackers
On Fri, May 13, 2016 at 2:37 PM, Kevin Grittner <kgrittn@gmail.com> wrote:
> On Fri, May 13, 2016 at 1:02 PM, David Fetter <david@fetter.org> wrote:
>> On Thu, Jan 22, 2015 at 02:41:42PM +0000, Kevin Grittner wrote:
>
>>> [ideas on how to pass around references to ephemeral relations]
>>
>> [almost 17 months later]
>>
>> It seems like now is getting close to the time to get this into
>> master.  The patch might have suffered from some bit rot, but the
>> design so far seems sound.
>>
>> What say?
>
> I had a talk with Tom in Brussels about this.  As I understood it,
> he wasn't too keen on the suggestion by Heikki (vaguely
> sorta-endorsed by Robert) of passing ephemeral named relations such
> as these tuplestores around in the structures currently used for
> parameter values.  He intuitively foresaw the types of problems I
> had run into trying to use the same structure to pass a relation
> (with structure and rows and columns of data) as is used to pass,
> say, an integer.

See, the thing that disappoints me about this is that I think we were
pretty closed to having the ParamListInfo-based approach working.  The
thing I liked about that approach is that we already know that any
place where you can provide parameters for a query, there will also be
an opportunity to provide a ParamListInfo.  And I think that
parameterizing a query by an ephemeral table is conceptually similar
to parameterizing it by a scalar value.  If we invent a new mechanism,
it's got to reach all of those same places in the code.

One other comment that I would make here is that I think that it's
important, however we pass the data, that the scope of the tuplestores
is firmly lexical and not dynamic.  We need to make sure that we don't
set some sort of context via global variables that might get used for
some query other than the one to which it's intended to apply.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: SELECT DISTINCT never uses an index?
Next
From: David Rowley
Date:
Subject: Re: SELECT DISTINCT never uses an index?