Re: GiST support for inet datatypes - Mailing list pgsql-hackers

From Emre Hasegeli
Subject Re: GiST support for inet datatypes
Date
Msg-id CAE2gYzy8TCx5pyn6xYPWnfH9QMyV0zo6EfUo27Q_Wyj3zCug+w@mail.gmail.com
Whole thread Raw
In response to Re: GiST support for inet datatypes  (Florian Pflug <fgp@phlo.org>)
Responses Re: GiST support for inet datatypes  (Florian Pflug <fgp@phlo.org>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: jsonb and nested hstore
Next
From: Andrew Dunstan
Date:
Subject: Re: jsonb and nested hstore