Re: Eliminating SPI / SQL from some RI triggers - take 3 - Mailing list pgsql-hackers

On Tue, Apr 21, 2026 at 5:50 AM Peter Eisentraut <peter@eisentraut.org> wrote:
> On 02.04.26 09:41, Amit Langote wrote:
> > There's another case in which it is not ok to use FlushArray and that
> > is if the index AM's amsearcharray is false (should be true in all
> > cases because the unique index used for PK is always btree).  Added an
> > Assert to that effect next to where SK_SEARCHARRAY is set in
> > ri_FastPathFlushArray rather than a runtime check in the dispatch
> > condition.
> >
> > Patch updated.  Also added a comment about invalidation requirement or
> > lack thereof for RI_FastPathEntry, rename AfterTriggerBatchIsActive()
> > to simply AfterTriggerIsActive(), fixed the comments in trigger.h
> > describing the callback mechanism.
> >
> > Will push tomorrow morning (Friday) barring objections.
>
> This commit contains a couple of calls
>
> ri_populate_fastpath_metadata((RI_ConstraintInfo *) riinfo,
>                                fk_rel, idx_rel);
>
> where the cast casts away the const-ness of riinfo.
>
> But this is kind of a lie, since the purpose of
> ri_populate_fastpath_metadata() is to modify riinfo.
>
> I think the right thing to do here is to unwind the const qualifiers up
> the stack.  See attached patch.

Thanks for the patch.  LGTM.

Are you planning to push it or do you want me to?

--
Thanks, Amit Langote