Re: OK, that's one LOCALE bug report too many... - Mailing list pgsql-hackers

From Lamar Owen
Subject Re: OK, that's one LOCALE bug report too many...
Date
Msg-id 3A22A956.602F6C6C@wgcr.org
Whole thread Raw
In response to Re: OK, that's one LOCALE bug report too many...  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Lamar Owen writes:
> >> 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.
> > Well, I'm looking at Red Hat 7.0 here and the locale variables are most
> > certainly getting ignored in the default compile.  Moreover, at no point
> > did strncmp() in glibc behave as you claim.

Try on RH 6.x.  It is possible RH 7 has this behavior fixed -- I have
not built _any_ no-locale RPM's since 6.5.3 -- and the last OS I built
that on was RH 6.2.  Amend my statement above to read 'caollation
sequence problem on RedHat 6.x, where x>0.'
> I'm having a hard time believing Lamar's recollection, also.

It's in the archives.  Not just my (often bad) recollections..... :-)

Of course, RH 7.0's behavior and RH 6.1's behavior (which was the
version I reported having the problem in the archive message thread) may
not be congruent.

>  I wonder
> if there could have been some other factor involved?  One possible line
> of thought: a non-locale-enabled compilation, installed to replace a
> locale-enabled one, would behave rather inconsistently if run on the
> same database used by the locale-enabled version (since indexes will
> still be in locale order).  Depending on what tests you did, you might
> well think that it was still running locale-enabled.

No index was involved.  The simple test script referred to in that
thread was all that was used.  I even went through an initdb cycle for
it.  However, I am willing to test again with fresh built 'no-locale'
RPM's on RH 6.2 and RH7 to see, if there is need.

All I need to do now is to make sure that the initscript starts
postmaster with the 'C' locale if the locale is set to 'en_US'.  Or is
that _really_ what we want, here?
> BTW: as of my commits of an hour ago, the above failure mode is no
> longer possible, since a non-locale-enabled Postgres will now refuse to
> start up in a database that shows any locale other than 'C' in pg_control.

Good.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11


pgsql-hackers by date:

Previous
From: selkovjr@mcs.anl.gov
Date:
Subject: Re: Indexing for geographic objects?
Next
From: Don Baccus
Date:
Subject: Re: Re: [NOVICE] Re: re : PHP and persistent connections