Re: GiST support for inet datatypes

Поиск
Список
Период
Сортировка
От Emre Hasegeli
Тема Re: GiST support for inet datatypes
Дата
Msg-id CAE2gYzy8TCx5pyn6xYPWnfH9QMyV0zo6EfUo27Q_Wyj3zCug+w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: GiST support for inet datatypes  (Florian Pflug <fgp@phlo.org>)
Ответы Re: GiST support for inet datatypes  (Florian Pflug <fgp@phlo.org>)
Список pgsql-hackers
2014-02-27 18:15, Florian Pflug <fgp@phlo.org>:
>> 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?

No, the problem is pg_upgrade. We can even benefit from this behavior of
pg_dump, if we would like to remove the operator classes on btree_gist.
Because of that behavior; users, who would upgrade by dump and restore,
will upgrade to the better default operator class without noticing. I am
not sure not notifying is the best think to do, though.

The problem is that pg_dump --binary-upgrade dumps objects in the extension
on the old cluster, not just the CREATE EXTENSION statement. pg_upgrade
fails to restore them, if the new operator class already exists on the new
cluster as the default. It effects all users who use the extension, even
if they are not using the inet and cidr operator classes in it.



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: jsonb and nested hstore
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: jsonb and nested hstore