Re: Dangling operator family after DROP TYPE

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