Re: Batch API for After Triggers - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: Batch API for After Triggers
Date
Msg-id 51BF8DF9.6050706@2ndquadrant.com
Whole thread Raw
In response to Re: Batch API for After Triggers  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: Batch API for After Triggers
List pgsql-hackers
On 06/18/2013 01:25 AM, Pavel Stehule wrote:
>> > and also one called
>> > UPDATED
>> > which would have two row vars called OLD and NEW
>> > so you would access it like e.g. IF UPDATED.OLD.id = 7
>> >
> nice idea
>
> +1
Much better naming than OLD_AND_NEW.

I'm not so sure about

OLD
NEW
INSERTED
DELETED

in that I imagine we'd want to pick one pair and stick with it. Since
using "INSERTED" / "DELETED" makes "UPDATED" make sense, and since "OLD"
and "NEW" are already used to refer to the magic variables of those
names in for each row triggers, I think INSERTED / UPDATED / DELETED is
the way to go.

INSERTED and UPDATED could just be views of the same data as UPDATED
that show only the OLD or only the NEW composite type fields. That'd
allow you to write a trigger without TG_OP tests in many cases, as
UPDATED would always contain what you wanted. It seems slightly weird to
have INSERTED and DELETED populated for an UPDATE, but when an UPDATE is
logically an INSERT+DELETE anyway...

-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services




pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: [RFC] Minmax indexes
Next
From: Craig Ringer
Date:
Subject: Re: [PATCH] Add transforms feature