> > 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?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
