Re: insensitive collations

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Daniel Verite <daniel(at)manitou-mail(dot)org>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: insensitive collations
Date: 2019-02-06 22:46:29
Message-ID: b8841338-93e6-6a27-933b-60d06c7c5a30@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 30/01/2019 16:30, Daniel Verite wrote:
> Peter Eisentraut wrote:
>
>> Another patch.

Another patch, with expanded documentation, more tests, and some code
cleanup.

>
> + <literal>ks</literal> key), in order for such such collations to act in
> a
>
> s/such such/such/

fixed

>
> + <para>
> + The pattern matching operators of all three kinds do not support
> + nondeterministic collations. If required, apply a different collation
> to
> + 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

Attachment Content-Type Size
v5-0001-Collations-with-nondeterministic-comparison.patch text/plain 150.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
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