This was surprising for my old tech lead who was sheepish on moving away from MySQL.
He would later refer to the MySQL bindings as “brain dead”
Additionally, modifying a trigger by drop/creating it would change behavior, unless you also drop/create every trigger (in the original order)
And then any second trigger that relies on that value
But I also think that it's unnecessarily problematic to make the order non-deterministic.
It just makes easier to understand what happens when triggers are invoked, without having to actually force specific cases by direct experimentation.
I did not even know that the standard prescribed a FIFO order, looks like a pretty bad idea to me, actually.
(To be fair, table columns share this characteristic.)
The table columns order is meaningless, but the triggers order is very relevant.
``` INSERT INTO foo SELECT * FROM bar ```
The harder problem however, is order in composite types.
PostgreSQL documentation is very good about comparing each feature to the standard.
For example, the SQL standard specifies that triggers fire in the historical order they are added to the table.
PostgreSQL chose to fire them alphabetically.
Technically nonconformant, but in practical terms, far better.