Doc: document that triggers can break referential integrity.
commit2fb7560cc8f8ba72fab840e7ae2b2b8c36e68c53
authorTom Lane <tgl@sss.pgh.pa.us>
Wed, 8 May 2024 15:13:40 +0000 (8 11:13 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Wed, 8 May 2024 15:13:40 +0000 (8 11:13 -0400)
tree8ed8df24b00b68a1ba9efa720e98189682b73a7d
parent482e108cd38db5366c52a6b1f4180f34c1796155
Doc: document that triggers can break referential integrity.

User-written triggers can modify or block the effects of SQL update
and delete operations.  That includes operations that are executed
to implement foreign keys' referential integrity actions (such as
ON UPDATE SET NULL or ON DELETE CASCADE).  Therefore it's possible
for a misdesigned trigger to result in a database state that violates
the foreign key constraint.

While this isn't great, the alternatives seem worse: in particular,
refusing to fire triggers for such updates would break many valuable
use-cases.  We could also try to recheck the constraint after the
action, but that'd roughly double the already-high cost of FK
constraint enforcement, for no benefit in normal cases.  So we've
always considered that it's on the trigger programmer's head to
avoid breaking RI actions.  This was never documented anywhere,
though.  Add a para to the Triggers chapter to explain it.

Laurenz Albe, David Johnston, Tom Lane

Discussion: https://postgr.es/m/b81fe38fcc25a81be6e2e5b3fc1ff624130762fa.camel@cybertec.at
doc/src/sgml/trigger.sgml