Skip site navigation (1) Skip section navigation (2)

Re: Compressing the AFTER TRIGGER queue

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>,"Jim Nasby" <jim(at)nasby(dot)net>
Cc: "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Dean Rasheed" <dean(dot)a(dot)rasheed(at)gmail(dot)com>, "PostgreSQL Hackers" <pgsql-hackers(at)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Compressing the AFTER TRIGGER queue
Date: 2011-08-04 13:40:28
Message-ID: 4E3A5AFC020000250003FA46@gw.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-hackers
Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Aug 3, 2011 at 6:05 PM, Jim Nasby <jim(at)nasby(dot)net> wrote:
>> Not sure how much this relates to this discussion, but I have
>> often wished we had AFTER FOR EACH STATEMENT triggers that
>> provided OLD and NEW recordsets you could make use of. Sometimes
>> it's very valuably to be able to look at *all* the rows that
>> changed in a transaction in one shot.
> 
> Yeah, that would be awesome.  I think some of our competitors
> provide exactly that feature...
 
If I remember correctly, MS SQL Server and Sybase ASE provide
INSERTED and DELETED relations in triggers instead of NEW and OLD
records.  In a FOR EACH ROW trigger the relation contains only one
row.
 
This is related to the thread on BEFORE triggers, in that these
products require that you UPDATE the row in the base table to modify
it (normally by joining to the INSERTED relation), making the latest
values available to other trigger code, and providing a clear
distinction between the values coming in to the trigger and the
latest values in the database.
 
-Kevin

In response to

Responses

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2011-08-04 13:42:31
Subject: Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https
Previous:From: Peter GeogheganDate: 2011-08-04 13:17:23
Subject: Re: TRUE/FALSE vs true/false

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group