Обсуждение: 9.1beta1 "collate" test failure
Hello all, while packaging 9.1 beta1, I noticed that the "collate" test case now fails (see attached regression.diffs). It seems to work when I run this under LANG= LANGUAGE= (i. e. in C locale), but it fails under both en_US.UTF-8 and de_DE.UTF-8. Is this just a bug/quirk/expectation of the test suite, i. e. should I always run the tests under the C locale? Or does it actually point towards an unexpected behaviour? Thanks, Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Вложения
Martin Pitt <mpitt@debian.org> writes: > while packaging 9.1 beta1, I noticed that the "collate" test case now > fails (see attached regression.diffs). It seems to work when I run > this under LANG= LANGUAGE= (i. e. in C locale), but it fails under > both en_US.UTF-8 and de_DE.UTF-8. [ raised eyebrow... ] What platform? This seems to point towards "C" locale not doing what it is supposed to ... regards, tom lane
Tom Lane [2011-05-10 10:03 -0400]: > [ raised eyebrow... ] What platform? This seems to point towards "C" > locale not doing what it is supposed to ... After your comment I checked locales on my system, and for some reason I had an /usr/lib/locales/C.UTF-8/ besides the usual locale-archive. I cleaned this up, and it works now. Sorry for the noise! Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Martin Pitt <mpitt@debian.org> writes: > Tom Lane [2011-05-10 10:03 -0400]: >> [ raised eyebrow... ] What platform? This seems to point towards "C" >> locale not doing what it is supposed to ... > After your comment I checked locales on my system, and for some reason > I had an /usr/lib/locales/C.UTF-8/ besides the usual locale-archive. I > cleaned this up, and it works now. Hmm ... I think that's probably still a bug, actually. Apparently what happened is that initdb injected an entry for "C" with encoding UTF8 into pg_collation, and then that was used instead of the intended "all-encodings" C entry, and then since the actual LC_COLLATE string wasn't precisely "C" we didn't go down the strcmp() code path but used whatever the locale file said to do ... which evidently wasn't really "C" behavior. We probably need to tweak initdb to be real sure it won't add entries that conflict with the built-in ones. This is already prohibited by CREATE COLLATION but initdb has to bypass that check. Thanks for the report! regards, tom lane