public inbox for [email protected]
help / color / mirror / Atom feedFrom: Amit Langote <[email protected]>
To: Peter Eisentraut <[email protected]>
Cc: Junwang Zhao <[email protected]>
Cc: Chao Li <[email protected]>
Cc: Haibo Yan <[email protected]>
Cc: Pavel Stehule <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Cc: Tomas Vondra <[email protected]>
Subject: Re: Eliminating SPI / SQL from some RI triggers - take 3
Date: Tue, 21 Apr 2026 09:52:55 +0900
Message-ID: <CA+HiwqE6ErHnebB4feVf9u0_0y4VjAGTtwuXPkX0-ktfdPL9Mw@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CA+HiwqF4C0ws3cO+z5cLkPuvwnAwkSp7sfvgGj3yQ=Li6KNMqA@mail.gmail.com>
<CA+HiwqFwZ6WLRbY8R7VC7JVp5Jot6ktZOkr9wDxTjoK=W1SgdQ@mail.gmail.com>
<CA+HiwqF_Kz=R8juHJBiOATvabWSOugK4VaGOxoJ_n=E2c7UM9w@mail.gmail.com>
<CA+HiwqHCB7kcbspkhaLN9enoj5x=ehzhFM4PXDgWUUP8Px41GA@mail.gmail.com>
<[email protected]>
<CA+HiwqHpVtP485wEKuXdOkdoZWhvVvfFH40-og07Jp3MPx21eg@mail.gmail.com>
<CAEG8a3JWHkJSXe9nNcVK7wnYKUEqWuMGFDhy5BynB_9tEjmEUg@mail.gmail.com>
<CA+HiwqFjfumKrWy03q5M309xJJVYt0WgGfH6AZ8BjFhSwppwsQ@mail.gmail.com>
<CAEG8a3JjP1LaKSv-r3AMJLRyLMzENJrKshWsDvDouMPM_sizmA@mail.gmail.com>
<CA+HiwqFQ+ZA7hSOygv4uv_t75B3r0_gosjadetCsAEoaZwTu6g@mail.gmail.com>
<CA+HiwqHdB0r8z6Mut13BxpYNq2W-os+Arju4mcZbCyU9PeaVog@mail.gmail.com>
<CAEG8a3K5ayVNkCDnK9OtNb+4OY0chJtW6ObgEOSFjqyymQda8Q@mail.gmail.com>
<CA+HiwqGJYCgEs_F-LBtrRdx-Y969LMr-OVogjFXU6U-0q5bOwQ@mail.gmail.com>
<CA+HiwqF2Ma6R_QyjfPBvFreYbezFpGcwASJE0a2bM+Y0jvof+g@mail.gmail.com>
<[email protected]>
On Tue, Apr 21, 2026 at 5:50 AM Peter Eisentraut <[email protected]> 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
view thread (63+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Eliminating SPI / SQL from some RI triggers - take 3
In-Reply-To: <CA+HiwqE6ErHnebB4feVf9u0_0y4VjAGTtwuXPkX0-ktfdPL9Mw@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox