On Thu, Feb 10, 2011 at 10:41 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Tue, Feb 8, 2011 at 9:48 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> In contrast, ALTER EXTENSION ADD doesn't presuppose that you couldn't
>>> add the object to multiple extensions; and it has a natural inverse,
>>> ALTER EXTENSION DROP. I am not necessarily suggesting that we will ever
>>> allow either of those things, but I do suggest that we should pick a
>>> syntax that doesn't look like it's being forced to conform if we ever
>>> want to do it. The DROP case at least seems like it might be wanted
>>> in the relatively near future.
>
>> Yep.
>
> Actually, it occurs to me that the need for ALTER EXTENSION DROP could
> be upon us sooner than we think. The cases where an extension upgrade
> script would need that are
> (1) you want to remove some deprecated piece of the extension's API;
> (2) you want to remove some no-longer-needed internal function.
> Without ALTER EXTENSION DROP it's flat out impossible to do either.
>
> Deprecated API is not exactly far to seek in our contrib modules,
> either --- the example that just reminded me of this is hstore's =>
> operator, which we're already going so far as to print warnings about.
> We're not going to get to remove that until at least one release after
> we support ALTER EXTENSION DROP.
>
> So I'm thinking it'd be smart to expend the small amount of additional
> effort needed to support DROP right off the bat. I think that
> AlterExtensionAddStmt could be extended with an add/drop boolean for
> a net addition of only a few dozen lines of code, most of that being a
> suitable search-and-delete function in pg_depend.c.
>
> Any objections?
No, I was pretty much just waiting for you to arrive at the same
conclusion I'd already reached. :-)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company