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

From: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Don Baccus <dhogaza(at)pacifier(dot)com>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: OK, that's one LOCALE bug report too many...
Date: 2000-11-25 19:34:00
Message-ID: 3A201428.EEE826A0@wgcr.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut wrote:
> Lamar Owen writes:
> > Yes, I want to ignore their default.

> If you want to do that then the infinitely better solution is to compile
> without locale support in the first place. (Make the locale-enabled
> server a separate package.) Alternatively, the locale of the postgres
> user to POSIX.

Ok, let me repeat -- the '--enable-locale' setting will not affect the
collation sequence problem on RedHat. If you set PostgreSQL to use
locale, it uses it. If you configure PostgreSQL to not use locale, the
collation set by LANG, LC_ALL, or LC_COLLATE is _STILL_ honored, thanks
to the libc used.

During the 6.5.x cycle, I built, for performance reasons, RPM's without
locale/multibyte support. These were referred to as the 'nl' RPM's.
Please see the thread I referred to to see how running with the
'non-locale' RPM's did not in the least solve the problem or change the
symptoms.

Setting the locale environment for the postmaster process is a
possibility, but I'll have to do some testing to see if there are any
interaction problems. And this still only helps RPM users, as my
initscript is not part of the canonical tarball.

> > I can do things in the initscript if necessary. That only helps the
> > RPM's, though, not those from-source RedHat installations.

> The subject of this whole discussion was IIRC the "default Red Hat
> installation". Those who compile from source can always make more
> informed decisions about what features to enable.

Those who compile from source and configure for no locale support will
get a nasty surprise on RedHat 6.1 and later.

Even though a different library function is used to do the comparison
for sorts and orderings, libc (in particular, glibc 2.1) _still_ uses
the LC_ALL, LANG, or LC_COLLATE setting to determine collation. For the
--enable-locale case, the function used is strcoll(); if not,
strncmp(). See varstr_cmp() in src/backend/utils/adt/varlena.c.

IOW, it is advisable to always enable locale on RedHat, as then you can
at least know what to expect. And you then will still get unexpected
results unless you do some locale work -- and, unfortunately, RedHat
6.x's locale documentation was sketchy at best; nonexistent at worst. I
haven't seen RedHat 7's printed documentation yet, so I can't comment on
it.

For reference on this issue, please see the archives, in particular the
following messages:
http://www.postgresql.org/mhonarc/pgsql-hackers/1999-12/msg00678.html
http://www.postgresql.org/mhonarc/pgsql-hackers/1999-12/msg00685.html
(where I got the function names above....)
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2000-11-25 19:34:02 Re: psql: anyone ever notice?
Previous Message Vadim Mikheev 2000-11-25 18:56:51 Re: Are pg_control contents really variable-length?