On Feb28, 2014, at 15:45 , Emre Hasegeli <e...@hasegeli.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
