|From:||Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>|
|To:||Daniel Verite <daniel(at)manitou-mail(dot)org>|
|Subject:||Re: insensitive collations|
|Views:||Raw Message | Whole Thread | Download mbox|
On 30/01/2019 16:30, Daniel Verite wrote:
> Peter Eisentraut wrote:
>> Another patch.
Another patch, with expanded documentation, more tests, and some code
> + <literal>ks</literal> key), in order for such such collations to act in
> s/such such/such/
> + <para>
> + The pattern matching operators of all three kinds do not support
> + nondeterministic collations. If required, apply a different collation
> + the expression to work around this limitation.
> + </para>
> It's an important point of comparison between CI collations and
> contrib/citext, since the latter diverts a bunch of functions/operators
> to make them do case-insensitive pattern matching.
> The doc for citext explains the rationale for using it versus text,
> maybe it would need now to be expanded a bit with pros/cons of
> choosing citext versus non-deterministic collations.
possibly addressed by the expanded documentation
> The current patch doesn't alter a few string functions that could
> potentially implement collation-aware string search, such as
> replace(), strpos(), starts_with().
> ISTM that we should not let these functions ignore the collation: they
> ought to error out until we get their implementation to use the ICU
> collation-aware string search.
I have addressed that. Many of these end up at the same one or two
low-level C function, so the checking just happens there.
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
|Next Message||Justin Pryzby||2019-02-06 23:21:11||Re: dsa_allocate() faliure|
|Previous Message||Daniel Gustafsson||2019-02-06 22:18:22||Inconsistent error handling in the openssl init code|