Re: Collation rules and multi-lingual databases
От | Dennis Gearon |
---|---|
Тема | Re: Collation rules and multi-lingual databases |
Дата | |
Msg-id | 3F43ECB5.8090405@fireserve.net обсуждение исходный текст |
Ответ на | Re: Collation rules and multi-lingual databases (Greg Stark <gsstark@mit.edu>) |
Ответы |
Re: Collation rules and multi-lingual databases
|
Список | 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 по дате отправления: