Re: insensitive collations - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: insensitive collations
Date
Msg-id 3e5bfc15-61e4-ecdc-81b2-55d036717a10@2ndquadrant.com
Whole thread Raw
In response to Re: insensitive collations  (Andreas Karlsson <andreas@proxel.se>)
Responses Re: insensitive collations  (Andreas Karlsson <andreas@proxel.se>)
List 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


pgsql-hackers by date:

Previous
From: Haribabu Kommi
Date:
Subject: Re: New function pg_stat_statements_reset_query() to reset statisticsof a specific query
Next
From: Peter Eisentraut
Date:
Subject: Re: insensitive collations