On Fri, 7 Sep 2001, Tom Lane wrote:
> <cnliou@eurosport.com> writes:
> > The document says: "Also, if more than one trigger is
> > defined for the same event on the same relation, the
> > order of trigger firing is unpredictable.
>
> Yup, and it means what it says.
>
> > My another question is: When both UPDATE trigger (and
> > its trigger function) and UPDATE CASCADE constraint
> > are both defined, is the custom UPDATE trigger or the
> > UPDATE CASCADE constraint fired first?
>
> > I wish the constraint will be fired first.
>
> That seems fairly arbitrary; someone else might wish the opposite,
> depending on the details of what they want to do.
>
> If we were to modify the code to make the firing order predictable,
> I'd want it to be user-controllable. A simple hack that comes to
> mind is to fire triggers in alphabetical order by name --- then you
> can easily arrange for custom triggers to fall either before or after
> system-generated ones. But perhaps someone else has a better idea.
I think that'd probably work, although I think that you probably
want to ensure that deferred constraint triggers run after normal
triggers and immediate constraints when you're running statements
in their own implicit transactions, since that would model the
behavior (check on commit) better.
