Re: contrib/citext versus collations - Mailing list pgsql-hackers

From Tom Lane
Subject Re: contrib/citext versus collations
Date
Msg-id 19683.1307478181@sss.pgh.pa.us
Whole thread Raw
In response to Re: contrib/citext versus collations  (Greg Stark <gsstark@mit.edu>)
Responses Re: contrib/citext versus collations
List pgsql-hackers
Greg Stark <gsstark@mit.edu> writes:
> On Mon, Jun 6, 2011 at 9:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The most workable alternative that I can see is to lobotomize citext so
>> that it always does lower-casing according to the database's "default"
>> collation, which would allow us to pretend that its notion of equality
>> is not collation-sensitive after all.

> That would also mean that 9.1's citext will be no worse than 9.0, it
> just won't have the 9.1 collation goodness.

On further reflection, I'm wondering exactly how much goodness to chop
off there.  What I'd originally been thinking was to just lobotomize the
case-folding step, and allow citext's comparison operators to still
respond to input collation when comparing the folded strings.  However,
I can imagine that some combinations of languages might produce pretty
weird results if we do that.  Should we lobotomize the comparisons too?
Or is the ability to affect the sort order valuable enough to put up
with whatever corner-case funnies there might be?

> Random thought -- the collation used for citext is not really the same
> as the default collation for ordering in sql. Perhaps it could be
> stored in the typmod?

Again, I'm wondering whether that's really a good idea.  I think the
currently implemented behavior of citext (fold and compare both act
according to input collation) is really the right thing ... we just
can't do it all yet.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: reducing the overhead of frequent table locks - now, with WIP patch
Next
From: Robert Haas
Date:
Subject: Re: reducing the overhead of frequent table locks - now, with WIP patch