| От | Tom Lane |
|---|---|
| Тема | Re: Trigger firing order |
| Дата | |
| Msg-id | 3318.975553238@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Trigger firing order ("Alex Bolenok" <abolen@chat.ru>) |
| Список | pgsql-general |
"Alex Bolenok" <abolen@chat.ru> writes:
> peroon=# INSERT INTO t_foo (foo_value) VALUES (2000);
> NOTICE: fn_foo_ains: Start
> NOTICE: fn_foo_ains: End
> NOTICE: fn_bar_ains: Start
> NOTICE: fn_bar_ains: End
Looking at the code, it seems that all AFTER triggers are implicitly
handled as DEFERRED triggers, ie, they're queued up and executed at
end of statement. This seems wrong to me --- DEFERRED mode is useful,
certainly, but it shouldn't be the only form of AFTER trigger.
Also, it'd seem to me that DEFERRED mode ought to mean defer till end
of transaction, not just end of statement...
Jan, any comments here?
regards, tom lane
В списке pgsql-general по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера