> >
But with certain packaged products who create their own triggers, I won't
>> have control over this.
I don't have a lot of sympathy for that argument. If the product is
capable of creating Postgres-compatible triggers at all, it should be
aware that the name is a significant property, and hence provide some
mechanism for selecting a name. Even if it somehow forgot about the
firing-order property, you can't seriously claim that it's our problem
to cater for combinations of client-side code that each think they can
choose trigger names in a vacuum. What if they choose the same name?
Well replication tools which are based on triggers do not let us do that. And if they let me do that it would become too tedious to use them.
If I have a trigger which add primary key to my inserted row ("before trigger"). Now if I plan to create new set of triggers for AUDITING or replication (where either I have no flexibility of choosing a name or the trigger name has to follow a standard), then I need to change all my existing triggers and rename them. Luckily I have ALTER TRIGGER statement to help me (some database don't have that feature), but it could be a substantial work depending on number of trigger I have.
Note, too, that you can leave but disable the existing triggers and define
your own triggers with whatever name you require and simply call the same
function as the existing trigger.
Isn't that bit of a trouble if I have to do that for every trigger?
I guess such re-naming could introduce problems with applications but that
is unlikely.
Actually it can cause issues. e.g. when I want to remove a table from replication set (all the triggers must get dropped). Now if I have modified a trigger/created another with a different name, that table will still be part of set.
I was going to propose to work on developing an additional clause "ORDER n" for CREATE TRIGGER statement. Triggers with lowest order gets called first.
Any two triggers who have same order will get called based on their sorting order of their name.
I can always define my triggers with a huge negative number. Now it does not matter if I add any more triggers in future.
Before proposing this change I wanted to make sure that others in community as well think that this could add value.
