mirror of
https://github.com/postgres/postgres.git
synced 2025-07-30 11:03:19 +03:00
Doc: clarify how triggers relate to transactions.
Laurenz Albe, per gripe from Nathan Long. Discussion: https://postgr.es/m/161953360822.695.15805897835151971142@wrigleys.postgresql.org
This commit is contained in:
@ -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
|
||||
|
@ -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
|
||||
|
Reference in New Issue
Block a user