On Feb28, 2014, at 15:45 , Emre Hasegeli <emre@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
