On Mon, Sep 15, 2014 at 11:45 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Peter Geoghegan <p...@heroku.com> writes: > > On Mon, Sep 15, 2014 at 8:28 AM, Alexander Korotkov > > <aekorot...@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. ------ With best regards, Alexander Korotkov.
