Re: locale support

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

In response to

Browse pgsql-hackers by date

  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!!!