From 2fb7560cc8f8ba72fab840e7ae2b2b8c36e68c53 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Wed, 8 May 2024 11:13:40 -0400 Subject: [PATCH] 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 | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/doc/src/sgml/trigger.sgml b/doc/src/sgml/trigger.sgml index a5390ff644..31626536a2 100644 --- a/doc/src/sgml/trigger.sgml +++ b/doc/src/sgml/trigger.sgml @@ -355,6 +355,17 @@ + If a foreign key constraint specifies referential actions (that + is, cascading updates or deletes), those actions are performed via + ordinary SQL update or delete commands on the referencing table. + In particular, any triggers that exist on the referencing table + will be fired for those changes. If such a trigger modifies or + blocks the effect of one of these commands, the end result could + be to break referential integrity. It is the trigger programmer's + responsibility to avoid that. + + + trigger arguments for trigger functions -- 2.11.4.GIT