On Wed, 26 May 2004, Alvaro Herrera wrote:
> I'm missing one item: deferred triggers. The problem with this is that
> the deftrig queue is not implemented using normal Lists, so there's no
> efficient way to reassign to the parent when the subtransaction commits.
> Also I'm not sure what should happen to the "immediate" pointer --- a
> subtransaction should have it's own private copy, or it should inherit
> the parent's? Please whoever implemented this speak up (Stephan
> Szabo?), as I'm not sure of the semantics.
[I haven't had a chance to look at the patch, because I'm at work, so you
may already have throught about/coded for some of the things below,
but...]
The immediate pointer basically points at the end of the queue from the
last scanning of the trigger queue (since any "immediate" triggers from
before that would have been run at that time there's no reason to scan
from the beginning).
As a related side question I just thought of (and wish I had earlier),
what's the correct behavior of SET CONSTRAINTS when setting a constraint
to immediate mode in the subtransaction case? In the single transaction
case, we change whether we consider the constraint deferred (or set the
"all"), reset the immediate pointer to the beginning of the queue, and
allow the end of statement scan to do what should hopefully be the right
thing. If one sets a constraint to immediate in a subtransaction,
does/should it cause the immediate check of pending events from its
parent? And does that revert when the transaction ends?
Before thinking about that, I figured that each subtransaction would have
a private trigger queue and then that the immediate pointer would be
private in each queue (starting as NULL when the subtransaction started)
and that if items were copied/reassigned at subtransaction end, the parent
transaction's immediate would move to just after that point after the
copy. Now, I'm not entirely sure.