Re: msvc++ build of 8.2.4 and encodings
От | Andrew Dunstan |
---|---|
Тема | Re: msvc++ build of 8.2.4 and encodings |
Дата | |
Msg-id | 46D637EB.5000103@dunslane.net обсуждение исходный текст |
Ответ на | msvc++ build of 8.2.4 and encodings (Charlie Savage <cfis@savagexi.com>) |
Ответы |
Re: msvc++ build of 8.2.4 and encodings
|
Список | pgsql-hackers |
Charlie Savage wrote: > Hope this is the right place for this post... > > I'm been trying out the msvc++ build scripts for postgresql 8.2.4 on > my development laptop (using window xp pro). > > I noticed the sort orders of queries changed. Investigating more, > encodings don't seem to be working as expected. > > Using a MSVC++ build: > > > CREATE DATABASE test1 WITH ENCODING = 'utf8'; > > > show all > > "lc_collate";"English_United States.1252" > "lc_ctype";"English_United States.1252" > "lc_messages";"C" > "lc_monetary";"C" > "lc_numeric";"C" > "lc_time";"C" > > Using a MSYS build: > > > CREATE DATABASE test1 WITH ENCODING = 'utf8'; > > > show all > > "lc_collate";"en_US.UTF-8" > "lc_ctype";"en_US.UTF-8" > "lc_messages";"C" > "lc_monetary";"C" > "lc_numeric";"C" > "lc_time";"C" > > In both cases, the database clusters were created like this: > > initdb ---locale=c --encoding=utf8; > > That seems most unlikely - without the superfluous dash it should set both lc_collate and lc_ctype to C. Please try the following in both cases: initdb --no-locale --encoding=utf8 data pg_controldata data | grep LC_ If it doesn't show this: LC_COLLATE: C LC_CTYPE: C then that's a bug. Or if after that you connect to the instance and "show lc_collate" or "show lc_ctype" don't likewise show C then that's a bug. Are you by any chance loading a library that calls setlocale() ? cheers andrew
В списке pgsql-hackers по дате отправления: