On Mon, Sep 15, 2014 at 11:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Peter Geoghegan <pg@heroku.com> writes: > On Mon, Sep 15, 2014 at 8:28 AM, Alexander Korotkov > <aekorotkov@gmail.com> wrote: >> Rename such opclasses and make them not default. >> Create new default opclasses with bitwise comparison functions. >> Write recommendation to re-create indexes with default opclasses into >> documentation.
> I certainly think this should be fixed if at all possible, but I'm not > sure about this plan. Can we really rename an opclass without > consequence, including having that respected across pg_upgrade?
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.
I've read thread about gist opclass for inet type. But that case is more difficult because conflict is between builtin opclass and contrib opclass. This case seems to be much simpler: we need to change builtin opclass to builtin opclass and contrib opclass to contrib opclass. I realized that it's problematic to rename builtin opclass due to pg_upgrade. However, it seems still possible to create new opclass and make it default.