Horton

Re: delta relations in AFTER triggers

Marti Raudsepp <marti@juffo.org>

View thread View on postgr.es
From: Marti Raudsepp <marti@juffo.org>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Kevin Grittner <kgrittn@ymail.com>, David Fetter <david@fetter.org>, Robert Haas <robertmhaas@gmail.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2014-07-29T07:41:33Z
Lists: pgsql-hackers 
On Tue, Jul 29, 2014 at 9:49 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> I dislike this proposal - it is strongly inconsistent with current trigger
> design

The real point I was trying to convey (in my previous email) is that
these declarations should be part of the trigger *function* not the
function-to-table relationship. CREATE TRIGGER shouldn't be in the
business of declaring new local variables for the trigger function.
Whether we define new syntax for that or re-use the argument list is
secondary.

But the inconsistency is deliberate, I find the current trigger API
horrible. Magic variables... Text-only TG_ARGV for arguments...
RETURNS trigger... No way to invoke trigger functions directly for
testing.

By not imitating past mistakes, maybe we can eventually arrive at a
language that makes sense.

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.