Re: Why are triggers semi-deferred?

On Tue, 6 May 2003, Philip Warner wrote:

> At 08:20 AM 5/05/2003 -0700, Stephan Szabo wrote:
> >it might be better to make times that the
> >triggers can run be choosable (with the spec behavior becoming default
> >eventually) because we've got backward compatibility issues and we've kind
> >overloaded the trigger system to do the foreign keys which have their own
> >timing issues.
>
> I think you are right here too; we need some way to make the triggers
> function according to the spec, as well as to preserve compatibility for
> constraint settings -- at least constrint triggers should fire when the
> constraints expect it, and normal triggers should fire when the spec says
> they should fire.

Actually, we'll probably want to allow it for normal triggers as well. I
think it's likely to break current triggers that people are using or at
least change semantics. For example, triggers that were made by
users that are doing some checks that currently assume that the full
set of actions have already been done, or one that does stuff outside the
database that now has to worry about stuff that used to be before it
erroring after it (sure it was unsafe before but now it's more unsafe).
Some of these will be rewritable (esp if we get statement triggers that
can see new/old rowsets), but I don't know if we want to force that.

[from other message]
>...which seems weird to me. Is this something that needs fixing in 7.3.3?

I think it's likely to be too large to be safe to put into 7.3.x. Just
changing the times isn't too hard I think (rather than unconditionally
adding to the queue, determine if its immediate and run it and put the
deferred ones into the queue I think) but that doesn't deal with the other
timing issues which should be part of that.