Re: contrib/citext versus collations

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: contrib/citext versus collations
Дата
Msg-id BANLkTinm6bpkaA-DSOVxnamq5bPRBvAqxA@mail.gmail.com
обсуждение исходный текст
Ответ на contrib/citext versus collations  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: contrib/citext versus collations
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: reducing the overhead of frequent table locks - now, with WIP patch
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: reducing the overhead of frequent table locks - now, with WIP patch