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 →
-
Try again to fix the MSVC build
- 151ffcf6d8c1 17.0 landed
-
Additional unicode primitive functions.
- a02b37fc0832 17.0 landed
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