On Thu, Feb 10, 2011 at 10:41 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Tue, Feb 8, 2011 at 9:48 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
