Extensions versus pg_upgrade

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Extensions versus pg_upgrade
Дата
Msg-id 20783.1297184036@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: Extensions versus pg_upgrade  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Re: Extensions versus pg_upgrade  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
It just occurred to me that the extensions patch thoroughly breaks
pg_upgrade, because pg_upgrade imagines that it can control the specific
OIDs assigned to certain SQL objects such as data types.  That is of
course not gonna happen for objects within an extension.  In fact, since
part of the point of an extension is that the set of objects it packages
might change across versions, it wouldn't be sensible to try to force
OID assignments even if there were a practical way to do it.

Offhand the only escape route that I can see is for a binary upgrade to
not try to install a newer version of an extension, but just duplicate
all the contained objects exactly.  Which is probably less than trivial
to do --- we could get part of the way there by having pg_dump not
suppress the member objects in --binary-upgrade mode, but then we need
some awful kluge to re-establish their pg_depend links to the extension.
In any case that would ratchet the priority of ALTER EXTENSION UPGRADE
back up to a must-have-for-9.1, since pg_upgrade would then leave you
with a non-upgraded extension.

Now what?
        regards, tom lane


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

Предыдущее
От: Noah Misch
Дата:
Сообщение: Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql
Следующее
От: Robert Haas
Дата:
Сообщение: Re: postponing some large patches to 9.2