Re: BUG #6172: DROP EXTENSION error without CASCADE

Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
> ... My fix is
> to have deleteDependencyRecordsFor use true for skipExtensionDeps.

On further reflection, there's some merit in that fix too. The question
is what do we think should happen if the pre-existing shell operator
belongs to another extension. It seems like the reasonable alternatives
are

(1) delete those pg_depend entries and allow the current extension to
take ownership.

(2) throw an error.

What you suggest above would result in (2), whereas what I was thinking
of would result in (1).

The case where this would actually happen is where extension A creates
some operator, and mentions some other operator as its commutator or
negator, but never gets around to defining the other operator. Then
extension B comes along and tries to fill in the other operator
definition. Do we want to let that happen, or do we want to throw an
error on the grounds that this sort of interconnection of two extensions
was almost certainly not intended? (Note that I rather doubt that
dropping either extension alone, afterwards, would clean up nicely,
since we have no code that would remove the oprcom/oprnegate linkage.)

A completely different line of thought is that maybe extension
membership records shouldn't be created at all for a shell operator,
on the grounds that it's not a real object but only a placeholder until
it's filled in.

One somewhat analogous situation is where we create a shell type and
then fill it in later. That code uses skipExtensionDeps = true and
so will end up throwing an error if the pre-existing membership is for
another extension. However, it's pretty hard to imagine a useful
situation where an extension would create a shell type and not fill it
in, so I'm not sure that this is a close analogy.

On the whole I'm starting to think that throwing an error is the best
thing. We could always relax that later, but going the other way might
be problematic.

regards, tom lane