Re: Extensions versus pg_upgrade

Поиск
Список
Период
Сортировка
От Dimitri Fontaine
Тема Re: Extensions versus pg_upgrade
Дата
Msg-id m2aai3nan8.fsf@2ndQuadrant.fr
обсуждение исходный текст
Ответ на Re: Extensions versus pg_upgrade  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Extensions versus pg_upgrade  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Extensions versus pg_upgrade
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Extensions versus pg_upgrade