Tom Lane wrote:
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > I know this is not PostgreSQL's fault but the broken locale data on
> > certain platforms. The problem makes it impossible to use PostgreSQL
> > RPMs in Japan.
> > I'm looking for solutions/workarounds for this problem.
> >> Build a set of RPMs without locale support?
> >> Run it with LC_ALL="C".
> > Both of them seem not ideal solutions for RPM. It would be nice if we
> > could distribute single binary and start up file in RPM.
> If you can find a non-intrusive way to do that, sure ... but I don't
> think that we should expend any great amount of effort, nor uglify the
> code, in order to cater to a demonstrably broken library on one
> particular platform.
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....
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,
either, because, at least on RH 6.1, strncmp() is buggered to use the
locale's collation.
The real solution is for the vendors to fix their broken locales.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
