Re: Fw:Re: Fw: gbt_var_consistent in contrib/btree_gist/btree_utils_var.c has internal-node type confusion on the <> strategy, bypassing exclusion constraints

Hi,

On Fri, 3 Jul 2026 at 19:20, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com> writes:
> > Are you planning on including it in the backpatch or to keep the
> > optimization just part of master, and the bug fix backpatched?
>
> I was intending to back-patch only the bug fixes, ie 0002 and 0003.
> If we make additional cosmetic changes to gbt_var_consistent(),
> I could go either way on whether to include those in the back-patch.
>

Sounds good.

> BTW, thinking some more about 0004: isn't it pointless to check
> gbt_var_node_pf_match in the gbt_var_consistent cases that
> only constrain the lower bound, that is LessEqual and Less? In
>
> retval = tinfo->f_cmp(query, key->lower, collation,
> flinfo) >= 0
> || gbt_var_node_pf_match(key, query, tinfo);
>
> if query >= key->lower then we must search the node, but if it
> isn't then the prefix match against upper can't succeed either.

Hmm, looks like the || gbt_var_node_pf_match(...) clause isn't
needed in the BTLessStrategyNumber and BTLessEqualStrategyNumber
cases. Those only compare against the lower bound, and if query
sorts before lower then it sorts before upper too, so a prefix
match against the (truncated) upper can never succeed there.
I tried changing it locally and ran the regression tests, all passed.

Regards,
Ayush