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

From Florian Pflug
Subject Re: GiST support for inet datatypes
Date
Msg-id 2366213C-6E48-483A-8CAF-C14E000EAC3E@phlo.org
Whole thread Raw
In response to Re: GiST support for inet datatypes  (Emre Hasegeli <emre@hasegeli.com>)
Responses Re: GiST support for inet datatypes  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: GiST support for inet datatypes  (Emre Hasegeli <emre@hasegeli.com>)
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: Changeset Extraction v7.6.1
Next
From: Robert Haas
Date:
Subject: Re: Changeset Extraction v7.6.1