Laurenz Albe <laurenz.a...@cybertec.at> writes: > Patch v3 is attached.
I agree with documenting this hazard, but I think it'd be better to do so in the "Triggers" chapter. There is no hazard unless you are writing user-defined triggers, which is surely far fewer people than use foreign keys. So I suggest something like the attached. regards, tom lane
diff --git a/doc/src/sgml/trigger.sgml b/doc/src/sgml/trigger.sgml index a5390ff644..99d8b75fc5 100644 --- a/doc/src/sgml/trigger.sgml +++ b/doc/src/sgml/trigger.sgml @@ -354,6 +354,20 @@ to avoid infinite recursion in such scenarios. </para> + <para> + <productname>PostgreSQL</productname> implements foreign key + constraints via system-defined <literal>AFTER</literal> triggers. + If a foreign key constraint specifies referential actions (that is, + cascading updates or deletes), these triggers issue ordinary SQL + update or delete commands on the referencing table to perform the + actions. In particular, any user-defined triggers on the referencing + table will be fired. 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. (Similar problems can arise in any case where different + triggers are working at cross-purposes.) + </para> + <para> <indexterm> <primary>trigger</primary>