From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Andreas Karlsson <andreas(at)proxel(dot)se>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: insensitive collations |
Date: | 2019-01-10 07:44:35 |
Message-ID: | 3e5bfc15-61e4-ecdc-81b2-55d036717a10@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 09/01/2019 19:49, Andreas Karlsson wrote:
> On 12/28/18 9:55 AM, Peter Eisentraut wrote:
>> Here is an updated patch.
>>
>> I have updated the naming to "deterministic", as discussed.
>
> Maybe this is orthogonal and best handled elsewhere but have you when
> working with string equality given unicode normalization forms[1] any
> thought?
Nondeterministic collations do address this by allowing canonically
equivalent code point sequences to compare as equal. You still need a
collation implementation that actually does compare them as equal; ICU
does this, glibc does not AFAICT.
> Would there be any point in adding unicode normalization support into
> the collation system or is this best handle for example with a function
> run on INSERT or with something else entirely?
I think there might be value in a feature that normalizes strings as
they enter the database, as a component of the encoding conversion
infrastructure. But that would be a separate feature.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2019-01-10 07:49:48 | Re: insensitive collations |
Previous Message | Haribabu Kommi | 2019-01-10 06:40:54 | Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query |