A properly written trigger shouldn't throw away data silently.

It should raise an exception, which indeed would cause the query to fail, and roll back the whole transaction (so no side effect is committed at all).

https://www.postgresql.org/docs/current/static/plpgsql-error...

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.

That’s the thing -what the app tier was doing wasn’t to complex for an ORM. Not by a long ahot.

The triggers that caused us problems generally came about to cover unrelated dba laziness and needed removed for sanity reasons anyway.

I am not arguing there cannot be a good case for triggers, just that when abused they cause a certain level of hell that is not worth it.