Stephan Szabo <[EMAIL PROTECTED]> writes:
> Okay. The former seems odd to me, especially for exception handling since
> Trigger D is making Trigger C immediate, but it could receive exceptions
> for Trigger B, so it couldn't assume it knows the source of the exception
> (C or something done due to C's execution) if it did something like:
> BEGIN
> SET CONSTRAINTS C IMMEDIATE;
> EXCEPTION WHEN ... THEN
> ...
> END;
> But it may not be a big deal.
>> It does occur to me though that there's another hazard here: refiring
>> trigger A which is already-in-progress. We'll need to add another flag
>> indicating that to the trigger queue entries ...
> Yeah, I thought of that after sending, but figured it was easily dealt
> with.
Hmm. Here's a slightly off the wall idea: following SET CONSTRAINTS,
scan the pending-triggers list twice. The first time, you determine
which triggers you need to fire, and mark them "in progress" by your
transaction. The second time through, you actually fire the ones you
marked, and change their marking to "done". The "in progress" ones
wouldn't be touched by the hypothetical inner SET CONSTRAINTS.
It wouldn't quite work to use just transaction ID as the marker, since
the inner SET CONSTRAINTS is very possibly done without using a
subtransaction. But command ID or query nesting level or some such
would work. I think the main concern here would be the space cost of
adding still another field to the trigger records ... is it worth it?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
