Add documentation about the behavior of BEFORE triggers and referential

integrity actions.

Stephan Szabo

diff --git a/doc/src/sgml/ref/create_trigger.sgml b/doc/src/sgml/ref/create_trigger.sgml
index cbf51f8b864a61716592179fa66bf13d0dc34b71..403ad856389ae87a28ef692157189a165b54a6f1 100644 (file)
--- a/doc/src/sgml/ref/create_trigger.sgml
+++ b/doc/src/sgml/ref/create_trigger.sgml
@@ -1,5 +1,5 @@
 
 
@@ -241,13 +241,25 @@ CREATE TRIGGER name { BEFORE | AFTE
       function that executes the desired commands.
      
     
+
    
   
 
   
    SQL specifies that multiple triggers should be fired in
    time-of-creation order.  PostgreSQL uses
-   name order, which was judged more convenient to work with.
+   name order, which was judged to be more convenient.
+  
+
+  
+   SQL specifies that BEFORE DELETE triggers on cascaded
+   deletes fire after the cascaded DELETE completes.
+   The PostgreSQL behavior is for BEFORE
+   DELETE to always fire before the delete action, even a cascading
+   one.  This is considered more consistent.  There is also unpredictable
+   behavior when BEFORE triggers modify rows that are later
+   to be modified by referential actions.  This can lead to contraint violations
+   or stored data that does not honor the referential constraint.