On Fri, Dec 6, 2024 at 12:15 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thanks for the report. I don't think it's wrong for the now-empty
> operator family to stick around: it has no direct dependency on the
> dropped type. Also, trying to make it go away would cause problems
> if another operator class for another type had been added to the
> family meanwhile. However, these things are bad:
>
> > Attempting to drop this operator family results in an error. Attempting
> > to do a dump/restore results in a syntax error on restore.
Agreed.
> It's intentional according to the code: in nbtvalidate.c
> we have
>
> if (op->is_func && op->number != BTORDER_PROC)
> {
> /* Optional support proc, so always a soft family dependency */
> op->ref_is_hard = false;
> op->ref_is_family = true;
> op->refobjid = opfamilyoid;
> }
>
> But I think we copied that pattern from other index AMs without
> thinking too hard about it.
That is accurate.
> Peter, any thoughts about this?
Nothing much to say about it.
I would just point out that using the built-in allequalimage function
is specifically documented as bad practice. After all, you as an
individual non-core opclass author don't have any control over its
behavior. At the same time, I do understand the temptation to use the
built-in allequalimage function. In practice most individual B-Tree
opclasses are *obviously* deduplication-safe, and it's convenient to
have a trivial function for that.
--
Peter Geoghegan
