Re: Dangling operator family after DROP TYPE

Peter Geoghegan <pg@bowt.ie> writes:
> On Fri, Dec 6, 2024 at 12:15 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.

Perhaps, but there are surely plenty of other ways to get into this
situation, when you have support functions whose signatures don't
involve the data type of the indexed column.

Here's a couple of proposed patches.  The first just makes
getObjectDescription robust against dangling
amproclefttype/amprocrighttype links.  (I did the same for pg_amop
entries, though that may be dead code, per comments below.)  I checked
that this allows dropping the busted opfamily.

The second one solves the problem more permanently by adding
dependencies on the types whenever we don't have an indirect
dependency through the operator or function.  Coverage checking shows
that the function case is actually hit in our regression tests (during
creation of contrib GiST opclasses), but the operator case isn't.
I think that the check for operators may be dead code, because AFAICS
from a quick look through opclasscmds.c, assignOperTypes will always
fill lefttype/righttype from the operator's input types and there's
nothing to override that.  But it's at least conceivable that the
index AM's amadjustmembers function would modify the
lefttype/righttype settings.  So I'm inclined to include that code
even if it does nothing today.

I looked at whether we could add a regression test for this, but
all of the cases that presently hit it are contrib extensions.
So there's no way to drop the data type without also dropping the
opfamily (which'd be likewise a member of the extension).  That
probably explains the lack of field reports of this old problem.
We could devise something no doubt, but it doesn't quite seem
worth the trouble and test cycles.

			regards, tom lane