Обсуждение: Clarify how triggers relate to transactions
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/13/sql-createtrigger.html Description: https://www.postgresql.org/docs/current/sql-createtrigger.html mentions the word "transaction" only once, in reference specifically to constraint triggers: "They can be fired either at the end of the statement causing the triggering event, or at the end of the containing transaction; in the latter case they are said to be deferred." 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."
On Tue, 2021-04-27 at 14:26 +0000, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/13/sql-createtrigger.html > Description: > > https://www.postgresql.org/docs/current/sql-createtrigger.html mentions the > word "transaction" only once, in reference specifically to constraint > triggers: "They can be fired either at the end of the statement causing the > triggering event, or at the end of the containing transaction; in the latter > case they are said to be deferred." > > 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 Yours, Laurenz Albe
Gotcha. Where would I go to make the PR?
On Wed, Apr 28, 2021, 7:24 AM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
On Tue, 2021-04-27 at 14:26 +0000, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/13/sql-createtrigger.html
> Description:
>
> https://www.postgresql.org/docs/current/sql-createtrigger.html mentions the
> word "transaction" only once, in reference specifically to constraint
> triggers: "They can be fired either at the end of the statement causing the
> triggering event, or at the end of the containing transaction; in the latter
> case they are said to be deferred."
>
> 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
Yours,
Laurenz Albe
On Wed, 2021-04-28 at 13:18 -0400, Nathan Long wrote: > Gotcha. Where would I go to make the PR? You'd create a patch against Git master and send it to this mailing list or pgsql-hackers. If you don't want it to fall between the cracks, register in the next commitfest where it can undergo peer review. Yours, Laurenz Albe
On Wed, Apr 28, 2021, at 2:18 PM, Nathan Long wrote:
Gotcha. Where would I go to make the PR?
There is no such PR feature; we don't use GitHub despite of having a mirror
there. As Laurenz said you should create a patch (using your preferred git
command) and attach to this thread. If you prefer, you can also send the patch
to pgsql-hackers ML (add the link to this thread). The next step is to register
your patch to the next commitfest [1] so we don't lose track of it. For a
complete reference about submitting a patch, take a look at [2].
Regards,
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: > > https://www.postgresql.org/docs/current/sql-createtrigger.html mentions the > > word "transaction" only once, in reference specifically to constraint > > triggers: "They can be fired either at the end of the statement causing the > > triggering event, or at the end of the containing transaction; in the latter > > case they are said to be deferred." > > > > 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. Yours, Laurenz Albe
Вложения
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
On Fri, 2021-07-30 at 16:20 -0400, Tom Lane wrote: > 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." > > > > 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? That is better, and I like your patch. Thanks! Keeping paragraphs short is a good thing. Yours, Laurenz Albe
Laurenz Albe <laurenz.albe@cybertec.at> writes:
> On Fri, 2021-07-30 at 16:20 -0400, Tom Lane wrote:
>> 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?
> That is better, and I like your patch. Thanks!
> Keeping paragraphs short is a good thing.
Pushed like that, then.
regards, tom lane