Re: Batch API for After Triggers

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Kevin Grittner <kgrittn(at)ymail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Batch API for After Triggers
Date: 2013-06-17 22:30:17
Message-ID: 51BF8DF9.6050706@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2013-06-17 22:33:30 Re: [PATCH] Add transforms feature
Previous Message Tomas Vondra 2013-06-17 21:42:03 Re: [RFC] Minmax indexes