Emre Hasegeli <e...@hasegeli.com> writes: > [ cites bug #5705 ] Hm. I had forgotten how thoroughly broken btree_gist's inet and cidr opclasses are. There was discussion at the time of just ripping them out despite the compatibility hit. We didn't do it, but if we had then life would be simpler now.
Perhaps it would be acceptable to drop the btree_gist implementation and teach pg_upgrade to refuse to upgrade if the old database contains any such indexes. I'm not sure that solves the problem, though, because I think pg_upgrade will still fail if the opclass is in the old database even though unused (because you'll get the complaint about multiple default opclasses anyway). The only simple way to avoid that is to not have btree_gist loaded at all in the old DB, and I doubt that's an acceptable upgrade restriction. It would require dropping indexes of the other types supported by btree_gist, which would be a pretty hard sell since those aren't broken. Really what we'd need here is for btree_gist to be upgraded to a version that doesn't define gist_inet_ops (or at least doesn't mark it as default) *before* pg_upgrading to a server version containing the proposed new implementation. Not sure how workable that is. Could we get away with having pg_upgrade unset the default flag in the old database? (Ick, but there are no very good alternatives here ...) BTW, I'd not been paying any attention to this thread, but now that I scan through it, I think the proposal to change the longstanding names of the inet operators has zero chance of being accepted. Consistency with the names chosen for range operators is a mighty weak argument compared to backwards compatibility. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers