On Fri, 7 Sep 2001, Bruce Momjian wrote:
> > > 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.
> >
> > Yes, the semantics of immediate and deferred triggers wouldn't change.
> > I'm just suggesting that when the system has a choice of legal firing
> > orders, it adopt an "alphabetical order" rule. AFAICS, all it would
> > take to implement this is for RelationBuildTriggers to sort the list
> > of triggers just after it's read them from pg_trigger and before it
> > inserts them into the TriggerDesc structure (ie, about line 638 of
> > trigger.c in current sources). The latter insertion is where they
> > are divided into categories, so the sorting would end up only affecting
> > the ordering within categories.
> >
> > The interesting question is not that, really, but whether an
> > alphabetical-ordering rule will be useful and convenient. I don't
> > recall exactly how the system chooses names for triggers that it creates
> > --- if the user can't control those at all then this idea may not be
> > helpful.
>
> Should we get a system where the user can control the firing, perhaps
> using oid order?
I don't think oid order would help, because what happens if you've say got
a trigger and then want to add another before it? I'd guess the most
general way would be to give triggers some kind of numeric ordering not
associated with anything else, but then you need ways to set it on create
trigger and probably an alter trigger way to change it. :( I'd guess that
there'd be a default value if you didn't set it, and that triggers of the
same value would run in indeterminate order like before.
