Re: contrib/citext versus collations

Greg Stark <gsstark(at)mit(dot)edu> writes:
> On Mon, Jun 6, 2011 at 9:14 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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