Re: OK, that's one LOCALE bug report too many...
От | Lamar Owen |
---|---|
Тема | Re: OK, that's one LOCALE bug report too many... |
Дата | |
Msg-id | 3A22A956.602F6C6C@wgcr.org обсуждение исходный текст |
Ответ на | Re: OK, that's one LOCALE bug report too many... (Peter Eisentraut <peter_e@gmx.net>) |
Список | 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 по дате отправления: