Skip site navigation (1) Skip section navigation (2)

Re: OK, that's one LOCALE bug report too many...

From: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: OK, that's one LOCALE bug report too many...
Date: 2000-11-25 00:41:46
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane wrote:
> Lamar Owen <lamar(dot)owen(at)wgcr(dot)org> writes:
> > Oh, and to make matters that much worse, on a RedHat system it doesn't
> > matter if you build with or without --enable-locale -- locale support is
> > in the libc used, and locale support gets used regardless of what you
> > select on the configure line :-(.
> But without --enable-locale, we will never call setlocale().
> Surely even RedHat is not so broken that they default to non-C locale
> in a program that has not called setlocale()?  That directly contravenes
> the letter of the ISO C standard, IIRC.

I just know this -- regression tests failed the same way with the 'nl'
non-locale RPM's as they did (and do) with the regular locale-enabled
RPM's.  Collation was the same, regardless of the --enable-locale
setting.  I got lots of 'bug' reports about the RPM's failing
regression, giving an unexpected sort order (see the archives -- the
best model thread's start post is: 
I was pretty ignorant back then of some of these issues :-).

Apparently RedHat is _that_ broken in that respect (among others). 
Thankfully some of RedHat's more egregious faults have been fixed in

But then again what Unix isn't broken in some respect :-).
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

In response to


pgsql-hackers by date

Next:From: Andrew BartlettDate: 2000-11-25 00:42:02
Subject: Re: SECURITY: psql allows symlink games in /tmp
Previous:From: Tom LaneDate: 2000-11-25 00:32:44
Subject: Re: OK, that's one LOCALE bug report too many...

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group