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
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 |