Re: Clarify how triggers relate to transactions

Laurenz Albe <laurenz.albe@cybertec.at> writes:
> On Wed, 2021-04-28 at 13:24 +0200, Laurenz Albe wrote:
>> On Tue, 2021-04-27 at 14:26 +0000, PG Doc comments form wrote:
>>> If I understand correctly, it would be helpful to add this sentence or a
>>> corrected version of it: "Triggers always execute in the same transaction as
>>> the triggering event, and if a trigger fails, the transaction is rolled
>>> back."

>> Good idea in principle, but I'd put that information on
>> https://www.postgresql.org/docs/current/trigger-definition.html

> Here is a proposed patch for this.

I think this is a good idea, but I felt like you'd added the extra
sentences in not-terribly-well-chosen places.  For instance, your
first addition in trigger.sgml is adding to a para that talks about
triggers for tables, while the next para talks about triggers for
views.  So it seems unclear whether the statement is meant to apply
to view triggers too.

I think it'd work out best to make this a separate para after the
one that defines before/after/instead-of triggers.  How do you
like the attached?

            regards, tom lane

diff --git a/doc/src/sgml/ref/create_trigger.sgml b/doc/src/sgml/ref/create_trigger.sgml
index 3f4b5acc7b..e4afa1c01d 100644
--- 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
index f1a845f756..7e2654493b 100644
--- 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