Laurenz Albe <laurenz.albe@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>