Re: BUG #5356: citext not acting like case insensitive search

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

In response to

Responses

Browse pgsql-bugs by date

  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