Re: Collation rules and multi-lingual databases - Mailing list pgsql-general

From Dennis Gearon
Subject Re: Collation rules and multi-lingual databases
Date
Msg-id 3F43ECB5.8090405@fireserve.net
Whole thread Raw
In response to Re: Collation rules and multi-lingual databases  (Greg Stark <gsstark@mit.edu>)
Responses Re: Collation rules and multi-lingual databases  (Greg Stark <gsstark@mit.edu>)
List 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@sss.pgh.pa.us> writes:
>
>
>
>>Greg Stark <gsstark@mit.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 ...
>>
>>
>
>
>


pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Buglist
Next
From: "David Olbersen"
Date:
Subject: Re: move to usenet?