Skip site navigation (1) Skip section navigation (2)

Re: BUG #6172: DROP EXTENSION error without CASCADE

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, "Hitoshi Harada" <umi(dot)tanuki(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #6172: DROP EXTENSION error without CASCADE
Date: 2011-08-22 15:02:33
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

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


Dimitri Fontaine     PostgreSQL : Expertise, Formation et Support

In response to

pgsql-bugs by date

Next:From: Robert HaasDate: 2011-08-22 16:34:15
Subject: Re: BUG #6165: documentation bug in plpgsql-declarations.html and plpgsql-statements.html (or plpgsql parser bug)
Previous:From: Tom LaneDate: 2011-08-22 14:39:00
Subject: Re: BUG #6172: DROP EXTENSION error without CASCADE

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group