Re: LIKE predicate and ERROR: 42P22: could not determine which collation to use for string comparison - HINT: Use the COLLATE clause ...

(Horribly red face)

All my fault.    It turns out I had applied a source-code change for some additional dtracing which I had merged forward from an older version but which was incorrect in V9.    After removing that it works fine.

Really sorry about that ....

John Lumby

----------------------------------------
> To: johnlumby(at)hotmail(dot)com
> CC: pgsql-bugs(at)postgresql(dot)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(at)sss(dot)pgh(dot)pa(dot)us
>
> John Lumby <johnlumby(at)hotmail(dot)com> writes:
> > I do have other databases in my cluster which probably explains the different 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 initdb 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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs