postgres (planner, runtime) should then object on
those grounds.
So - I *think* there is a bug, either that the query should not have been
rewritten (if collation does indeed make the rewrite incorrect), or else it
should have planned and executed the rewritten query.
I re-ran this on PG 9.1.
#x27;"; # should fail
### snip
----
> To: johnlu...@hotmail.com
> CC: pgsql-bugs@postgresql.org
> Subject: Re: [BUGS] LIKE predicate and ERROR: 42P22: could not determine
> which collation to use
her
sample point and it exhibits the same bug).
Is your output different? Do you think you could post the output you get?
Regards,
cts it?
I would have had LANG=C and LC_ALL=C exported. Do you have
any system where you could try an initdb with those environment vars exported?
What are the values of relevant locale-type env vars when you ran initdb on
your test sys?
Regards
(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
