From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
Cc: | "Michael Gould" <mgould(at)intermodalsoftwaresolutions(dot)net>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #5356: citext not acting like case insensitive search |
Date: | 2010-03-01 18:25:28 |
Message-ID: | 20854.1267467928@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
"David E. Wheeler" <david(at)kineticode(dot)com> writes:
> Michael managed to fix this issue by moving citext to the "public"
> schema. The question is, why would citext operators work in the public
> schema but not when they're in some other schema? Is `=` resolving to
> `TEXT = TEXT` if the "iss" schema isn't in the search path?
Now that I think a bit, not having the operators in the search path
would cause exactly that. The parser will be faced with
citext = unknown_literal
and the only operator that it can find that is relevant at all is
text = text, which can be applied by using the implicit cast from
citext to text. So that's what it will do.
Not sure if there is anything we can do to make this much nicer.
Removing the implicit cast seems like a cure worse than the disease,
particularly because it would result in throwing a "no such operator"
error rather than actually doing what Michael would like.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2010-03-01 18:38:05 | Re: BUG #5355: locale incorrectly comma-separates "(null)" |
Previous Message | Tom Lane | 2010-03-01 18:17:08 | Re: BUG #5356: citext not acting like case insensitive search |