Re: BUG #6172: DROP EXTENSION error without CASCADE - Mailing list pgsql-bugs

From Dimitri Fontaine
Subject Re: BUG #6172: DROP EXTENSION error without CASCADE
Date
Msg-id m2r54debg6.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Re: BUG #6172: DROP EXTENSION error without CASCADE  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
Tom Lane <tgl@sss.pgh.pa.us> writes:
> 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.)

I don't think we should let that happen.  We currently support self
contained extensions and I don't see opening the door this way as a
feature.

> 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.

+1

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #6172: DROP EXTENSION error without CASCADE
Next
From: Robert Haas
Date:
Subject: Re: BUG #6165: documentation bug in plpgsql-declarations.html and plpgsql-statements.html (or plpgsql parser bug)