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

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.