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
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 |