Re: Extensions versus pg_upgrade

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Extensions versus pg_upgrade
Дата
Msg-id 21596.1297186247@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Extensions versus pg_upgrade  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Ответы Re: Extensions versus pg_upgrade  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Список pgsql-hackers
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> Now what?

> What would be the problem with pg_upgrade acting the same as a
> dump&reload cycle as far as extensions are concerned?

Um, how about "it doesn't work"?

The reason that data type OIDs have to be preserved, for example, is
that they might be out on disk.  Suppose that you have the cube
extension installed and there are some user tables containing columns of
type cube[].  Those arrays are going to have type cube's OID embedded in
them.  If cube has a different OID after pg_upgrade then the arrays are
broken.

Even letting an extension script run and create data types that weren't
there at all before is problematic, since those types could easily claim
OIDs that need to be reserved for pre-existing types that appear later
in the dump script.

Similar issues arise for the other cases where pg_upgrade is forcing OID
assignments; it's not doing that just for fun.
        regards, tom lane


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

Предыдущее
От: Euler Taveira de Oliveira
Дата:
Сообщение: Re: Allow pg_archivecleanup to ignore extensions
Следующее
От: Alex Hunsaker
Дата:
Сообщение: Re: arrays as pl/perl input arguments [PATCH]