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

From Peter Eisentraut
Subject Re: Eliminating SPI / SQL from some RI triggers - take 3
Date
Msg-id 548600ed-8bbb-4e50-8fc3-65091b122276@eisentraut.org
Whole thread
In response to Re: Eliminating SPI / SQL from some RI triggers - take 3  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: Eliminating SPI / SQL from some RI triggers - take 3
List pgsql-hackers
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.


Attachment

pgsql-hackers by date:

Previous
From: Ayush Tiwari
Date:
Subject: [PATCH] Fix column name escaping in postgres_fdw stats import
Next
From: Masahiko Sawada
Date:
Subject: Support logical replication of DDLs, take2