Re: ALTER EXTENSION UPGRADE, v3

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: ALTER EXTENSION UPGRADE, v3
Дата
Msg-id 24959.1296754716@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: ALTER EXTENSION UPGRADE, v3  (Florian Pflug <fgp@phlo.org>)
Ответы Re: ALTER EXTENSION UPGRADE, v3  ("David E. Wheeler" <david@kineticode.com>)
Re: ALTER EXTENSION UPGRADE, v3  (Robert Haas <robertmhaas@gmail.com>)
Re: ALTER EXTENSION UPGRADE, v3  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Список pgsql-hackers
Florian Pflug <fgp@phlo.org> writes:
> I fully agree. The extension infrastructure should provide basic support
> for upgrades, not every kind of bell and whistle one could possible think of.

Maybe somewhere around here we should stop and ask why we are bothering
with any of this.  The original idea for an extension concept was that
(1) some collection of objects could be designated as a module
(2) pg_dump would be taught to dump "LOAD MODULE foo" instead of the
individual objects
(3) the way you'd do an upgrade is to dump and reload into a database
that has available a newer definition of the module's content.

Given that pg_upgrade is now considered a supported piece of the system,
ISTM that most real-world upgrade scenarios will be accomplished with
pg_upgrade relying on provision (3).  It looks to me like we're talking
about adding a large amount of complication --- both for the core
database and for module authors --- in order to provide a duplicate
solution for that.  Why should we bother?  Especially, why should we
bother in version 1 of the feature?  This could all be added later if
we determine there's really sufficient demand, but right now we have
no experience to show whether there is demand or not.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: is_absolute_path incorrect on Windows
Следующее
От: "David E. Wheeler"
Дата:
Сообщение: Re: ALTER EXTENSION UPGRADE, v3