Doc: clarify how triggers relate to transactions.

tglsfdc · tglsfdc · commit 469150a240dd · 2021-09-01T17:24:59.000-04:00
Laurenz Albe, per gripe from Nathan Long. Discussion: https://postgr.es/m/161953360822.695.15805897835151971142@wrigleys.postgresql.org
diff --git a/doc/src/sgml/ref/create_trigger.sgml b/doc/src/sgml/ref/create_trigger.sgml
@@ -175,6 +175,10 @@ CREATE [ OR REPLACE ] [ CONSTRAINT ] TRIGGER <replaceable class="parameter">name
   </para>
 
   <para>
+   <indexterm>
+    <primary>trigger</primary>
+    <secondary>constraint trigger</secondary>
+   </indexterm>
    When the <literal>CONSTRAINT</literal> option is specified, this command creates a
    <firstterm>constraint trigger</firstterm>.  This is the same as a regular trigger
    except that the timing of the trigger firing can be adjusted using
diff --git a/doc/src/sgml/trigger.sgml b/doc/src/sgml/trigger.sgml
@@ -122,6 +122,15 @@
     row in the view is identified as needing to be operated on.
    </para>
 
+   <para>
+    The execution of an <literal>AFTER</literal> trigger can be deferred
+    to the end of the transaction, rather than the end of the statement,
+    if it was defined as a <firstterm>constraint trigger</firstterm>.
+    In all cases, a trigger is executed as part of the same transaction as
+    the statement that triggered it, so if either the statement or the
+    trigger causes an error, the effects of both will be rolled back.
+   </para>
+
    <para>
     A statement that targets a parent table in an inheritance or partitioning
     hierarchy does not cause the statement-level triggers of affected child
