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-28 15:30:37 |
Message-ID: | 85B75D9F-CC17-41FC-B9FE-FC2237ABF16A@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Feb28, 2014, at 15:45 , Emre Hasegeli <emre(at)hasegeli(dot)com> wrote:
> 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.
Hm, what if we put the new opclass into an extension of its own, say inet_gist,
instead of into core?
Couldn't we then remove the inet support from the latest version of btree_gist
(the one we'd ship with 9.4)? People who don't use the old inet opclass could
then simply upgrade the extension after running pg_upgrade to get rid of the
old, broken version. People who *do* use the old inet opclass would need to
drop their indices before doing that, then install the extension inet_gist,
and finally re-create their indices.
People who do nothing would continue to use the old inet opclass.
inet_gist's SQL script could check whether btree_gist has been upgrade, and
if not fail with an error like "btree_gist must be upgraded to at least version
x.y before inet_gist can be installed". That would avoid failing with a rather
cryptic error later.
best regards,
Florian Pflug
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2014-02-28 15:36:38 | Re: Custom Scan APIs (Re: Custom Plan node) |
Previous Message | Amit Kapila | 2014-02-28 15:25:20 | Re: Patch: show relation and tuple infos of a lock to acquire |