Re: locale support
От | Tatsuo Ishii |
---|---|
Тема | Re: locale support |
Дата | |
Msg-id | 20010214185216S.t-ishii@sra.co.jp обсуждение исходный текст |
Ответ на | Re: locale support (Lamar Owen <lamar.owen@wgcr.org>) |
Список | pgsql-hackers |
> Tatsuo, what is LC_ALL (or the other locale envvars) set to when you run > the program? The man page for setlocale() on my machine documents that > the main() starts in C or POSIX locale mode by default. The call to > setlocale(LC_ALL, "") reads the envvars and sets the locale > accordingly. Maybe RedHat's 6.2J isn't setting up the locale properly > to begin with? See what /etc/sysconfig/i18n contains -- if it is empty > or doesn't exist, then locale is simply not set up. But you specfically > mention the particular locale.... It's "ja_JP.eucJP". Definitely that locale exists, so I guess the contents is broken... > Ok, what combinations _do_ work? We _know_ C or POSIX works -- but > which ones don't work, on RH >6.1? While I want to make sure that a > broken locale data set isn't used, I also want to make sure that a good > locale set isn't thrown out, either. Forcing to LC_COLLATE=C is > overkill, IMHO. And building without locale support doesn't work, I guess most single byte locales work. However I seriously doubt that locales for multibyte language would work. > either, because, at least on RH 6.1, strncmp() is buggered to use the > locale's collation. Really? I see PostgreSQL installations without the locale support work just fine on RH 6.1J. > The real solution is for the vendors to fix their broken locales. Of course. -- Tatsuo Ishii
В списке pgsql-hackers по дате отправления: