The biggest problem I've had with triggers is that your application tier tells the database to do an update, it says it did it, and then the app shows the user the result.
But in the background, the trigger somehow overrode your changes, so the next time the user comes back they see different data than the app just told them was there.
Granted, this is arguably the wrong way to use triggers, but once it's become an invasive problem in your codebase it's incredibly hard to deal with. You can't remove the triggers for fear of what still relies on the side effects, and you don't want to query back the data for every update either. It ends up being like the polar opposite of functional programming - side effects everywhere.
In postgres you can handle this using the "returning" syntax for updates; then as long as the trigger runs before rather than after the update you don't have to lie about anything.
I'm not really sure that would help in the case we had.
Most of our code ran through an ORM, and the ORM assumes the DB either did what it asked, or the query fails. I don't want to have to abandon my ORM because I can't trust my "DBA" to not sabotage my queries.
A good ORM allows you to specify that a column may be changed server-side by triggers etc. on an update (or insert), and it will then make sure to retrieve the correct value after the fact, if necessary.
This is just a limitation of ORMs. After a certain complexity you really should just be making direct queries to your database and not relying on ORMs.
But in the background, the trigger somehow overrode your changes, so the next time the user comes back they see different data than the app just told them was there.
Granted, this is arguably the wrong way to use triggers, but once it's become an invasive problem in your codebase it's incredibly hard to deal with. You can't remove the triggers for fear of what still relies on the side effects, and you don't want to query back the data for every update either. It ends up being like the polar opposite of functional programming - side effects everywhere.