> No. And we don't know how to change the default opclass without > breaking things, either. See previous discussions about how we > might fix the totally-broken default gist opclass that btree_gist > creates for the inet type [1]. The motivation for getting rid of that > is *way* stronger than "it might be slow", but there's no apparent > way to make something else be the default without creating havoc.
Inet case was not the same. We tried to replace the default opclass in contrib with another one in core. It did not work because pg_dump --binary-upgrade dumps the objects of the extension which cannot be restored when there is a default opclass for the same data type. Changing the default opclasses should work if we make pg_dump --binary-upgrade dump the default opclasses with indexes and exclusion constraints. I think it makes sense to do so in --binary-upgrade mode. I can try to come with a patch for this. I cannot see a way to rename opclasses in core. I think we can live with default opclasses which are not named as type_ops. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers