Re: Collation rules and multi-lingual databases

From: Dennis Gearon <gearond(at)fireserve(dot)net>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org
Subject: Re: Collation rules and multi-lingual databases
Date: 2003-08-20 21:48:37
Message-ID: 3F43ECB5.8090405@fireserve.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

I think it would be nice, and I may write it eventually, to have a
function called:

COLLATION_VALUE( 'string', 'encoding' )

Which could be used like:

SELECT field_a, field_b
FROM table_a
GROUP BY COLLATION_VALUE( field_a )
ORDER BY COLLATION_VALUE( field_b );

or in other creative ways.

Greg Stark wrote:

>Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>
>
>
>>Greg Stark <gsstark(at)mit(dot)edu> writes:
>>
>>
>>>My understanding is that the entire set of localization parameters needs to be
>>>decided upon when the initdb is done and can never be changed later. Is that
>>>right?
>>>
>>>
>>No, not all of them are frozen. Unfortunately, the one you care about
>>(LC_COLLATE) is. The reason for this is that it determines index
>>ordering for textual columns, and so changing LC_COLLATE on the fly
>>produces instant corrupt indexes :-(
>>
>>
>
>Yeah, I really would be perfectly happy to have indexes be in "C" order and
>have my queries have to specifically specify the sort order in the ORDER BY
>clause, knowing they won't use the index.
>
>Well, ok, not quite perfectly happy. But in this case there are no indexes on
>the columns anyways so...
>
>
>
>>A solution for this is on the TODO list, but don't hold your breath ...
>>
>>
>
>
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Dennis Gearon 2003-08-20 21:58:03 Re: move to usenet?
Previous Message The Hermit Hacker 2003-08-20 21:45:35 Re: Mail server load