Re: Compressing the AFTER TRIGGER queue

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: Compressing the AFTER TRIGGER queue
Дата
Msg-id BD669E03-7295-46D2-8DF7-F7A927EB7B4E@nasby.net
обсуждение исходный текст
Ответ на Re: Compressing the AFTER TRIGGER queue  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Список pgsql-hackers
On Aug 4, 2011, at 8:40 AM, Kevin Grittner wrote:
> Robert Haas <robertmhaas@gmail.com> wrote:
>> On Wed, Aug 3, 2011 at 6:05 PM, Jim Nasby <jim@nasby.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.

Yeah, that sounds like how DB2 does it (though the relations were by default named NEW and OLD).

If there is agreement that having a NEW recordset that contains all the new records (or new values on updates) and an
OLDrecordset that contains all the old records, are there any other API issues that need to be resolved? How would this
actuallybe implemented? 
--
Jim C. Nasby, Database Architect                   jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Should we have an optional limit on the recursion depth of recursive CTEs?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Should we have an optional limit on the recursion depth of recursive CTEs?