On Tue, 16 Aug 2005, Tom Lane wrote:
> [ redirected to -hackers ]
>
> I wrote:
> > This suggests that we need a way to prevent immediate execution of
> > freshly queued triggers at the end of a command fired by an FK trigger.
> > If we could move them to the end of the trigger queue that the FK
> > operation itself is in, things would work reasonably well I think.
>
> After a quick look through the code, it seems like the way to do this
> is to add an extra bool parameter "nest_triggers" to _SPI_pquery, which
> when false would simply suppress its calls to AfterTriggerBeginQuery
> and AfterTriggerEndQuery --- thus causing any queued triggers to be
> queued in the same trigger list the FK is in. We'd then expose this
> parameter (only) via SPI_execute_snapshot, which is intended only for
> RI trigger use anyway.
This seems right to me. I'd thought that SQL wanted the user triggers to
be run after the updating directly, but reading it again, SQL03 at least
seems to just talk about adding state changes for after triggers to the
current trigger context AFAICS which means that the above seems to be what
is requested by the spec in general.
> I think this would take some generalization of afterTriggerInvokeEvents,
> which now might or might not find the target rel in the EState it's
> passed, but otherwise it doesn't seem too invasive. Thoughts?
That doesn't seem too bad really, looking at afterTriggerInvokeEvents it
doesn't look like it'd be that much work to change it to handle that case.
I can put a patch together to see what it looks like.
