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

0 files changed, 0 insertions, 0 deletions