Re: Mixing different LC_COLLATE and database encodings

Поиск
Список
Период
Сортировка
От Bill Moseley
Тема Re: Mixing different LC_COLLATE and database encodings
Дата
Msg-id 20060219041606.GB11754@hank.org
обсуждение исходный текст
Ответ на Re: Mixing different LC_COLLATE and database encodings  (Greg Stark <gsstark@mit.edu>)
Ответы Re: Mixing different LC_COLLATE and database encodings  (Martijn van Oosterhout <kleptog@svana.org>)
Список pgsql-general
On Sat, Feb 18, 2006 at 09:31:27PM -0500, Greg Stark wrote:
> Anything else and the collation just won't work properly. It will be
> expecting UTF-8 and be fed ISO-8859-1 strings, resulting in weird
> and sometimes inconsistent sort orders.

So if I have utf8 encoded text and the lc_collate is anything but
utf8 then sorting will be all wrong for any chars that don't map to
ASCII (>127).  Kind of a mess.


> There's a certain amount of feeling that using any locale other than C is
> probably not ever the right thing given the current functionality. Just about
> any database has some strings in it that are really just ascii strings like
> char(1) primary keys and other internal database strings. You may not want
> them being subject to the locale's collation for comparison purposes and you
> may not want the overhead of variable width character encodings.

Is the Holy Grail encoding and lc_collate settings per column?


Changing topics, but I'm going to play with different cluster
settings for collate.  If I create a cluster in given directory
is there any problems with moving that cluster (renaming the
directory)?

Thanks for your comments, Greg.


--
Bill Moseley
moseley@hank.org


В списке pgsql-general по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: Mixing different LC_COLLATE and database encodings
Следующее
От: Brendan Duddridge
Дата:
Сообщение: Same data, different results in Postgres vs. FrontBase