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

From Greg Stark
Subject Re: contrib/citext versus collations
Date
Msg-id BANLkTinm6bpkaA-DSOVxnamq5bPRBvAqxA@mail.gmail.com
Whole thread Raw
In response to contrib/citext versus collations  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: contrib/citext versus collations
List pgsql-hackers
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.  We could hope to improve this in
> future release cycles, but not till we've done the infrastructure work
> outlined above.  One bit of infrastructure that might be a good idea is
> a flag to indicate whether an equality operator's behavior is
> potentially collation-dependent, so that we could avoid taking
> performance hits in the normal case.
>
> Comments, other ideas?

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.

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? So you could declare different columns to be
case insensitive according to specific collations. And it would be
free to cast between them but would have to be explicit. I'm not sure
that's actually a good idea, it was just a first thought,

--
greg


pgsql-hackers by date:

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