Re: Add comments about fire_triggers argument in ri_triggers.c - Mailing list pgsql-hackers

From Amit Langote
Subject Re: Add comments about fire_triggers argument in ri_triggers.c
Date
Msg-id CA+HiwqF3RXW7BGv2PTs0Q73CJfUDseQSc=+hUsk==R64Uva87A@mail.gmail.com
Whole thread
In response to Re: Add comments about fire_triggers argument in ri_triggers.c  (Yugo Nagata <nagata@sraoss.co.jp>)
Responses Re: Add comments about fire_triggers argument in ri_triggers.c
List pgsql-hackers
On Fri, Mar 27, 2026 at 12:01 PM Yugo Nagata <nagata@sraoss.co.jp> wrote:
> On Fri, 27 Mar 2026 09:39:17 +0900
> Amit Langote <amitlangote09@gmail.com> wrote:
>
> > On Fri, Mar 27, 2026 at 12:56 AM Yugo Nagata <nagata@sraoss.co.jp> wrote:
> > >
> > > Hi,
> > >
> > > Thank you all for the review and comments.
> > >
> > > > Yes Amit, I agree that SPI_execute_snapshot() comments do provide some
> > > > context on AFTER triggers, but I still feel the newly added comment
> > > > in ri_PerformCheck() gives additional context on why the fire_triggers is
> > > > set to false.
> > >
> > > Yes, that is what I intended. The existing comments on
> > > SPI_execute_snapshot() explain how the fire_triggers parameter works,
> > > but I would like to add a comment explaining why the AFTER trigger for
> > > RI needs to set it to false.
> > >
> > > If the explanation of the effect of fire_triggers seems redundant, I am
> > > fine with the following shorter version:
> > >
> > > +        * Set fire_triggers to false to ensure that check triggers fire after all
> > > +        * RI updates on the same row are complete.
> >
> > Thanks for the updated patch.  Yes, adding the comment might be good,
> > but I'd suggest a small tweak:
> >
> > +        * Set fire_triggers to false to ensure that AFTER triggers
> > are queued in
> > +        * the outer query's after-trigger context and fire after all
> > RI updates on
> > +        * the same row are complete, rather than immediately.
> >
> > Two changes:
> >
> > * "check triggers" -> "AFTER triggers", since fire_triggers=false
> > affects any AFTER triggers queued during the SPI execution, not just
> > RI check triggers.
> >
> > * mention of the outer query's after-trigger context to explain the
> > mechanism by which the deferral works.
> >
> > Does that additional context help?
>
> Thank you for the suggestion.
> That looks good to me. It is clearer than the previous version.

Ok, will push the attached.

--
Thanks, Amit Langote

Attachment

pgsql-hackers by date:

Previous
From: Yugo Nagata
Date:
Subject: Re: Allow to collect statistics on virtual generated columns
Next
From: shveta malik
Date:
Subject: Re: Skipping schema changes in publication