Re: GiST support for inet datatypes

Поиск
Список
Период
Сортировка
От Florian Pflug
Тема Re: GiST support for inet datatypes
Дата
Msg-id 2366213C-6E48-483A-8CAF-C14E000EAC3E@phlo.org
обсуждение исходный текст
Ответ на Re: GiST support for inet datatypes  (Emre Hasegeli <emre@hasegeli.com>)
Ответы Re: GiST support for inet datatypes  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: GiST support for inet datatypes  (Emre Hasegeli <emre@hasegeli.com>)
Список pgsql-hackers
On Feb27, 2014, at 11:39 , Emre Hasegeli <emre@hasegeli.com> wrote:
> 2014-02-24 17:55, Bruce Momjian <bruce@momjian.us>:
> 
>> pg_upgrade has _never_ modified the old cluster, and I am hesitant to do
>> that now.  Can we make the changes in the new cluster, or in pg_dump
>> when in binary upgrade mode?
> 
> It can be possible to update the new operator class in the new cluster
> as not default, before restore. After the restore, pg_upgrade can upgrade
> the btree_gist extension and reset the operator class as the default.
> pg_upgrade suggests to re-initdb the new cluster if it fails, anyway. Do
> you think it is a better solution? I think it will be more complicated
> to do in pg_dump when in binary upgrade mode.

Maybe I'm missing something, but isn't the gist of the problem here that
pg_dump won't explicitly state the operator class if it's the default?

If so, can't we just make pg_dump always spell out the operator class
explicitly? Then changing the default will never change the meaning of
database dumps, so upgraded clusters will simply continue to use the
old (now non-default) opclass, no?

best regards,
Florian Pflug




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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Changeset Extraction v7.6.1
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Changeset Extraction v7.6.1