Re: Pre-proposal: unicode normalized text

Jeff Davis <pgsql@j-davis.com>

From: Jeff Davis <pgsql@j-davis.com>
To: Peter Eisentraut <peter@eisentraut.org>, pgsql-hackers@postgresql.org
Date: 2023-10-03T22:55:32Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Try again to fix the MSVC build

  2. Additional unicode primitive functions.

On Mon, 2023-10-02 at 10:47 +0200, Peter Eisentraut wrote:
> I think a better direction here would be to work toward making 
> nondeterministic collations usable on the global/database level and
> then 
> encouraging users to use those.
> 
> It's also not clear which way the performance tradeoffs would fall.
> 
> Nondeterministic collations are obviously going to be slower, but by
> how 
> much?  People have accepted moving from C locale to "real" locales 
> because they needed those semantics.  Would it be any worse moving
> from 
> real locales to "even realer" locales?

If you normalize first, then you can get some semantic improvements
without giving up on the stability and performance of memcmp(). That
seems like a win with zero costs in terms of stability or performance
(except perhaps some extra text->utext casts).

Going to a "real" locale gives more semantic benefits but at a very
high cost: depending on a collation provider library, dealing with
collation changes, and performance costs. While supporting the use of
nondeterministic collations at the database level may be a good idea,
it's not helping to reach the compromise that I'm trying to reach in
this thread.

Regards,
	Jeff Davis