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>, 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-27 18:35:02
Message-ID: 3A22A956.602F6C6C@wgcr.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message selkovjr 2000-11-27 18:36:42 Re: [HACKERS] Indexing for geographic objects?
Previous Message Don Baccus 2000-11-27 18:30:27 Re: Re: [NOVICE] Re: re : PHP and persistent connections