Re: Extensions versus pg_upgrade - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Extensions versus pg_upgrade
Date
Msg-id m2aai3nan8.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Re: Extensions versus pg_upgrade  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Extensions versus pg_upgrade  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:
> 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.

What if you just DROP FUNCTION in the upgrade script?

That said if the function is used in some expression index or worse,
triggers, you certainly want to give users the opportunity to delay the
step where the function is no more part of the extension from the step
where you get rid of it.

But if the function is implemented in C and the newer shared object has
removed it…

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

Given your phrasing about the size of this project, I can't see any
downside here.

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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Extensions versus pg_upgrade
Next
From: Tom Lane
Date:
Subject: Re: Extensions versus pg_upgrade