Re: delta relations in AFTER triggers

Marti Raudsepp <marti@juffo.org>

From: Marti Raudsepp <marti@juffo.org>
To: Kevin Grittner <kgrittn@ymail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Heikki Linnakangas <hlinnakangas@vmware.com>, Amit Khandekar <amit.khandekar@enterprisedb.com>, Robert Haas <robertmhaas@gmail.com>, David Fetter <david@fetter.org>, Alvaro Herrera <alvherre@2ndquadrant.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2014-09-03T20:55:00Z
Lists: pgsql-hackers
On Wed, Sep 3, 2014 at 10:49 PM, Kevin Grittner <kgrittn@ymail.com> wrote:
> Marti Raudsepp <marti@juffo.org> wrote:
>> The concept of "lightweight relations" that pop into existence when a
>> certain kind of trigger definition is used somewhere in the function
>> stack, without a CREATE TABLE, without being discoverable in
>> information_schema etc., I find needs some more justification than
>> I've seen in this thread. So far I've only heard that it's more
>> convenient to implement in the current PostgreSQL code base.
>
> It is required by the SQL standard.

I had a cursory read of the SQL 20nn draft and I don't get this
impression. The only place I could find discussing the behavior of
"transition tables" is in Foundation "4.39.1 General description of
triggers", which says:

"Special variables make the data in the transition table(s) available
to the triggered action. For a statement-level
trigger the variable is one whose value is a transition table."

There is no information about the scoping of such variables, so I
assume it refers to a regular locally scoped variable.

Did I miss something? Are you reading a different version of the spec?

Regards,
Marti


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.