Re: Patch for collation using ICU - Mailing list pgsql-hackers

From Palle Girgensohn
Subject Re: Patch for collation using ICU
Date
Msg-id 47900.62.148.39.163.1115591486.squirrel@62.148.39.163
Whole thread Raw
In response to Re: Patch for collation using ICU  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> Palle Girgensohn <girgen@pingpong.net> writes:
>>> I'm confused. I thought the ICU patches is intended for using on
>>> broken locale platforms?
>
>> It will sort correctly in *one* locale, using ICU. You still cannot mix
>> different locales in the same database cluster, the collation locale is
>> still fixed at initdb time, unfortunately.
>
> I thought the point of using ICU was to be able to dig out from under
> that restriction?

I think it might be quite possible to mix several locales, using ICU. It's
just that this is not what the patch does at moment. It just finds out the
locale set at initdb and uses it for collation with ICU.

Handling mixed locales for collation has a few hard problems, AFAIK.
First, isn't the main obstacle for mixing collations that indices require
a single well defined locale? I assume that locale dependant comparison
(collation) is used when indexing tuples, right? As long as a specific
locales collation is used for indexing text fields, I believe we cannot
easily mix different locales, right? Second, how do we tell the backend
which locale to use? Is there some SQL spec for this?

> It's a bit of a large pill to swallow if we will still
> have to throw it away someday to become SQL spec compliant.

What do we need to be SQL spec compliant in this respect?

/Palle




pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: pl/pgsql enabled by default
Next
From: Andrew - Supernews
Date:
Subject: Re: Views, views, views! (long)