Re: Batch API for After Triggers

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: Batch API for After Triggers
Дата
Msg-id 51BF8DF9.6050706@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: Batch API for After Triggers  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: Batch API for After Triggers  (Simon Riggs <simon@2ndQuadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: [RFC] Minmax indexes
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: [PATCH] Add transforms feature