Horton

Re: delta relations in AFTER triggers

Jim C. Nasby <jim@nasby.net>

View thread View on postgr.es
From: Jim Nasby <jim@nasby.net>
To: Heikki Linnakangas <hlinnakangas@vmware.com>, Kevin Grittner <kgrittn@ymail.com>, Amit Khandekar <amit.khandekar@enterprisedb.com>
Cc: Robert Haas <robertmhaas@gmail.com>, David Fetter <david@fetter.org>, Alvaro Herrera <alvherre@2ndquadrant.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2014-08-27T16:51:40Z
Lists: pgsql-hackers 
On 8/27/14, 2:23 AM, Heikki Linnakangas wrote:
> Does this make sense? In essence, make the relations work like PL/pgSQL variables do. If you squint a little, the new/old relation is a variable from the function's point of view, and a parameter from the planner/executor's point of view. It's just a variable/parameter that holds a set of tuples, instead of a single Datum.

Something to keep in mind is that users will definitely think about NEW/OLD as tables. I suspect that it won't be long after release before someone asks why they can't create an index on it. :)
-- 
Jim C. Nasby, Data Architect                       jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net

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.