From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Martin Pitt <mpitt(at)debian(dot)org> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: 9.1beta1 "collate" test failure |
Date: | 2011-05-10 15:38:32 |
Message-ID: | 17343.1305041912@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Martin Pitt <mpitt(at)debian(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Martin Pitt | 2011-05-10 16:20:23 | Changed behaviour of \' |
Previous Message | Bryant, Alex | 2011-05-10 14:59:18 | Re: Upgrading from 1.10 to 1.12 - cannot set up server |