Re: BUG #16333: position() function not equivalent to strpos() function when comparing citext

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: me(at)reynolds(dot)tj, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #16333: position() function not equivalent to strpos() function when comparing citext
Date: 2020-04-02 21:46:06
Message-ID: 28841.1585863966@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> Arguably, there is a misdesign here, however. Any function that does
> some kind of text-in-text search where citext could plausbily offer
> case-insensitive behavior will automatically fall back to the
> case-sensitive version if citext doesn't offer its own variant. The fix
> would technically need to be that citext offers its own variant of every
> potential such function, which is clearly not possible, or that casts
> between text and citext are more restricted, which would make citext
> nearly unusable.

Indeed. There are some hundreds of built-in functions that take one
or more text arguments; how many of them would need citext variants?

> Doesn't seem fixable. Collations are probably a better way of dealing
> with this.

Yeah, now that we can do non-deterministic collations, it seems like
citext is on the road to obsolescence. Do we have a documentation
example of how to build a simple CI collation?

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Kyotaro Horiguchi 2020-04-03 01:14:17 Re: [BUG] non archived WAL removed during production crash recovery
Previous Message Peter Eisentraut 2020-04-02 20:53:17 Re: BUG #16333: position() function not equivalent to strpos() function when comparing citext