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 ...
>>
>>
>
>
>
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 |