Re: Making AFTER triggers act properly in PL functions

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Making AFTER triggers act properly in PL functions
Дата
Msg-id 11830.1094598791@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Making AFTER triggers act properly in PL functions  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
Ответы Re: Making AFTER triggers act properly in PL functions  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
Список pgsql-hackers
Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> I misread then.  I thought that you were proposing that EndQuery look only
> at the per-query list and then add the deferred items that weren't fired
> to the main list but never go over that list.

It will have to re-examine the tail of the main list, as well as process
the current per-query list.  I haven't really done any coding yet, but
I think this could be done pretty easily by appending the per-query list
to the main list (an easy pointer swing) and then proceeding as before.
Or it might be better to do it in two phases --- I'm not sure how hard
it is to keep track of whether it's safe to recycle fully-fired events.
Knowing that you are processing triggers generated by the current query
might be a useful leg up on that task.

Also, it's probably reasonable to assume that SET CONSTRAINTS doesn't
queue any new triggers of its own, meaning that in any given EndQuery
call only one of these tasks (rescan old triggers or scan new ones)
can be needed.  That might or might not be worth exploiting.
        regards, tom lane


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

Предыдущее
От: Stephan Szabo
Дата:
Сообщение: Re: Making AFTER triggers act properly in PL functions
Следующее
От: Gaetano Mendola
Дата:
Сообщение: Re: Why does pg_stat_activity Truncate Queries?