On Tue, 7 Sep 2004, Tom Lane wrote:
> 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.
Hmm, if our current state of deferred triggers look like (in order)Trigger ATrigger BTrigger C
and triggers A and B are made immediate and scanning begins at the
beginning of the queue again, during the execution of the Trigger A
trigger function, if an update is done to a table with an immediate after
trigger (D), does the firing order look like:
Trigger A start Trigger D start Trigger D endTrigger A endTrigger B startTrigger B end
or something else? What if trigger D calls set constraints to make
Trigger C immediate?
