Re: Eliminating SPI / SQL from some RI triggers - take 3

On Tue, Apr 21, 2026 at 9:52 AM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> On Tue, Apr 21, 2026 at 5:50 AM Peter Eisentraut <peter(at)eisentraut(dot)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?

Pushed.

--
Thanks, Amit Langote