public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Ayush Tiwari <[email protected]>
Cc: 王跃林 <[email protected]>
Cc: pgsql-bugs <[email protected]>
Cc: 3764353996 <[email protected]>
Subject: 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
Date: Thu, 02 Jul 2026 12:54:17 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAJTYsWX1C5JLj92QdqEcArWs4XtXPog+yvyb6=X=_cghjXnkYQ@mail.gmail.com>
References: <AH*AvQCYKhQGVvPWi1GiU4oY.8.1781609375063.Hmail.3020001251@tju.edu.cn>
	<CAJTYsWWSx+5-kVaivB_znaQCk3TmHrO4QNNM-CD3AN-oOSmG8w@mail.gmail.com>
	<AGoA0AD5KvwQ8G7e6ofMyap6.3.1781760245047.Hmail.3020001251@tju.edu.cn>
	<[email protected]>
	<CAJTYsWX1C5JLj92QdqEcArWs4XtXPog+yvyb6=X=_cghjXnkYQ@mail.gmail.com>

Ayush Tiwari <[email protected]> writes:
> On Thu, 2 Jul 2026 at 20:08, Tom Lane <[email protected]> wrote:
>> None of this passes the smell test for me.  If it's unsafe to
>> call the type's f_eq function on a truncated key, how is it
>> any safer to call the f_cmp function?

> I think the difference is that for bit/varbit f_eq and f_cmp aren't the
> same kind of function.  f_eq is biteq (reads bit_len, does VARSIZE-8),
> while f_cmp is byteacmp (plain byte-wise, only needs the varlena
> header).

Oh!  You are right, the internal keys are *not* valid bit/varbit
values, just bytea.  The level of non-documentation in this code
is staggering.

So the actual API contract here is that f_eq etc. are to be used only
on leaf keys, while f_cmp is to be used only on internal keys.  It's
not too surprising that whoever added NotEqual support didn't know
that, it being documented nowhere.

It kind of looks actually like there's an expectation that all
internal keys are effectively bytea's; note the naming of
gbt_bytea_pf_match, despite the fact that it's applied to all
types under the purview of btree_utils_var.c.

Anyway, I think part of our work here has got to be to raise the
level of documentation of this code.  I've had it with having
to reverse-engineer details as fundamental as these.

			regards, tom lane

view thread (13+ 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]
  Subject: 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
  In-Reply-To: <[email protected]>

* 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