Re: Making AFTER triggers act properly in PL functions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Making AFTER triggers act properly in PL functions
Date
Msg-id 11830.1094598791@sss.pgh.pa.us
Whole thread Raw
In response to Re: Making AFTER triggers act properly in PL functions  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
Responses Re: Making AFTER triggers act properly in PL functions  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
List 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 by date:

Previous
From: Stephan Szabo
Date:
Subject: Re: Making AFTER triggers act properly in PL functions
Next
From: Gaetano Mendola
Date:
Subject: Re: Why does pg_stat_activity Truncate Queries?