(Horribly red face)
All my fault.=A0=A0=A0 It turns out I had applied a source-code change for =
some additional dtracing which I had merged forward from an older version b=
ut which was incorrect in V9.=A0=A0=A0 After removing that it works fine.
Really sorry about that ....
John Lumby
----------------------------------------
> To: johnlumby@hotmail.com
> CC: pgsql-bugs@postgresql.org
> Subject: Re: [BUGS] LIKE predicate and ERROR: 42P22: could not determine =
which collation to use for string comparison - HINT: Use the COLLATE clause=
...
> Date: Tue, 13 Dec 2011 14:04:02 -0500
> From: tgl@sss.pgh.pa.us
>
> John Lumby <johnlumby@hotmail.com> writes:
> > I do have other databases in my cluster which probably explains the dif=
ferent datlastsysoid.
>
> No, it wouldn't. datlastsysoid only counts objects created during
> initdb.
>
> [ thinks for a bit ] The most likely explanation for the different
> datlastsysoid value is that the number of pre-created pg_collation
> entries is quite a bit different on my box than yours, as a result of a
> different list from "locale -a". It's hard to see why that would have
> anything to do with your issue, but I have a feeling it does somehow.
>
> What platforms have you tried this on, exactly? I tried it on Fedora 14.
>
> > What are the values of relevant locale-type env vars when you ran initd=
b on your test sys?
>
> Shrug ... C. That's my normal working environment. I did try it with
> en_US.utf8 too, just for grins.
>
> regards, tom lane
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
=20=09=09=20=09=20=20=20=09=09=20=20