Re: Dangling operator family after DROP TYPE

On Fri, Dec 6, 2024 at 12:15 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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