Horton

Re: delta relations in AFTER triggers

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Heikki Linnakangas <hlinnakangas@vmware.com>
Cc: Kevin Grittner <kgrittn@ymail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Amit Khandekar <amit.khandekar@enterprisedb.com>, David Fetter <david@fetter.org>, Alvaro Herrera <alvherre@2ndquadrant.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2014-09-23T17:03:06Z
Lists: pgsql-hackers 
On Tue, Sep 23, 2014 at 12:46 PM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
> On 09/15/2014 05:25 PM, Kevin Grittner wrote:
> Now, how do we make the tuplestores work similarly? Here's what I think we
> should do:
>
> Add a new p_tableref_hook function pointer, similar to p_paramref_hook.
> Whenever the parser sees a RangeVar that it doesn't recognize (or actually,
> I think it should call it *before* resolving regular tables, but let's
> ignore that for now), it calls the p_tableref_hook. It can return a new
> RelationParam node (similar to regular Param), which contains a numeric ID
> for the table/tuplestore, as well as its tuple descriptor.
>
> For the execution phase, add a new array of Tuplestorestates to
> ParamListInfo. Similar to the existing array of ParamExternalDatas.

I haven't been following this issue closely, but this sounds like a
really nice design.

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

Commits

  1. Don't permit transition tables with TRUNCATE triggers.

  2. Pass EXEC_FLAG_REWIND when initializing a tuplestore scan.

  3. Faster expression evaluation and targetlist projection.

  4. Remove obsoleted code relating to targetlist SRF evaluation.

  5. Implement syntax for transition tables in AFTER triggers.