2014-02-19 16:52, Tom Lane <t...@sss.pgh.pa.us>: > Not at all, AFAICS. If it were okay to decide that some formerly-default > opclass is no longer default, then having such a command would be better > than manually manipulating pg_opclass.opcdefault --- but extension upgrade > scripts could certainly do the latter if they had to. The problem here > is whether it's upgrade-safe to make such a change at all; having > syntactic sugar doesn't make it safer.
It is not hard to support != operator on the new operator class. That would make it functionally compatible with the ones on btree_gist. That way, changing the default would not break pg_dump dumps, it would only upgrade the index to the new one. pg_upgrade dumps current objects in the extension. It fails to restore them, if the new operator class exists as the default. I do not really understand how pg_upgrade handle extension upgrades. I do not have a solution to this. It would be sad if we cannot make the new operator class default because of the btree_gist implementation which is not useful for inet data types. You wrote on 2010-10-11 about it [1]: > Well, actually the btree_gist implementation for inet is a completely > broken piece of junk: it thinks that convert_network_to_scalar is 100% > trustworthy and can be used as a substitute for the real comparison > functions, which isn't even approximately true. I'm not sure why > Teodor implemented it like that instead of using the type's real > comparison functions, but it's pretty much useless if you want the > same sort order that the type itself defines. [1] http://www.postgresql.org/message-id/8973.1286841...@sss.pgh.pa.us -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
