From: | Florian Pflug <fgp(at)phlo(dot)org> |
---|---|
To: | emre(at)hasegeli(dot)com |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Andreas Karlsson <andreas(at)proxel(dot)se>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: GiST support for inet datatypes |
Date: | 2014-02-27 16:15:32 |
Message-ID: | 2366213C-6E48-483A-8CAF-C14E000EAC3E@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Feb27, 2014, at 11:39 , Emre Hasegeli <emre(at)hasegeli(dot)com> wrote:
> 2014-02-24 17:55, Bruce Momjian <bruce(at)momjian(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2014-02-27 16:28:22 | Re: Changeset Extraction v7.6.1 |
Previous Message | Andres Freund | 2014-02-27 16:06:00 | Re: Changeset Extraction v7.6.1 |