On Tue, 7 Sep 2004, Tom Lane wrote: > Stephan Szabo <[EMAIL PROTECTED]> 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 A Trigger B Trigger 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 end Trigger A end Trigger B start Trigger B end or something else? What if trigger D calls set constraints to make Trigger C immediate? ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
