Re: Locale, Collation, ICU patch

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Locale, Collation, ICU patch
Date: 2008-04-04 09:29:59
Message-ID: 20080404092959.GB18988@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 03, 2008 at 06:54:50PM +0100, Gregory Stark wrote:
> The big gotcha is what collation to use when comparing with data in the system
> tables, especially the shared system tables. I think we do need to define a
> database-wide encoding and collation to use for system tables. (Unless we can
> get by with varchar_pattern_ops indexes on system tables?)

In my version I simply made that all system tables were in locale C,
standard binary sorting. Anything else is likely to blowup if you want
to start using multiple encodings. From a performance point of view
this is best, since you don't want the planner bogging down because the
user wants an expensive collation.

> b) They're using multiple collations for their data but only one "at a time".
> Either one per database or one per session. In which case they don't incur any
> overhead

The case I'm thinking of if people wanting some columns to be
case-insensetive. I'm not sure however if this will be in the first
version though.

Also, there isn't one-to-one correspondence between locales and
collations. There are many more collations and I hope we will support
that. The common variations are ascending/descending and
case-sensetivity.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Sam Mason 2008-04-04 11:41:16 Re: COPY Transform support
Previous Message Martijn van Oosterhout 2008-04-04 09:06:01 Re: modules