Re: Collation-aware comparisons in GIN opclasses

From: Emre Hasegeli <emre(at)hasegeli(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Geoghegan <pg(at)heroku(dot)com>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Collation-aware comparisons in GIN opclasses
Date: 2014-09-16 07:29:52
Message-ID: 20140916072952.GA31511@hasegeli.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2014-09-16 07:42:03 Re: Collation-aware comparisons in GIN opclasses
Previous Message Hannu Krosing 2014-09-16 07:27:55 Re: Anonymous code block with parameters