From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
---|---|
To: | lamar(dot)owen(at)wgcr(dot)org |
Cc: | tgl(at)sss(dot)pgh(dot)pa(dot)us, ncm(at)zembu(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: locale support |
Date: | 2001-02-14 09:52:16 |
Message-ID: | 20010214185216S.t-ishii@sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2001-02-14 16:24:51 | Open 7.1 items |
Previous Message | Vadim Mikheev | 2001-02-14 09:40:52 | Re: Recovery of PGSQL after system crash failing!!! |