Re: Extensions versus pg_upgrade

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Feb 8, 2011 at 9:48 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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?

regards, tom lane