Re: Pre-proposal: unicode normalized text
Peter Eisentraut <peter@eisentraut.org>
From: Peter Eisentraut <peter@eisentraut.org>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Jeff Davis <pgsql@j-davis.com>, pgsql-hackers@postgresql.org
Date: 2023-10-11T06:51:27Z
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 10.10.23 16:02, Robert Haas wrote: > On Tue, Oct 10, 2023 at 2:44 AM Peter Eisentraut <peter@eisentraut.org> wrote: >> Can you restate what this is supposed to be for? This thread appears to >> have morphed from "let's normalize everything" to "let's check for >> unassigned code points", but I'm not sure what we are aiming for now. > > Jeff can say what he wants it for, but one obvious application would > be to have the ability to add a CHECK constraint that forbids > inserting unassigned code points into your database, which would be > useful if you're worried about forward-compatibility with collation > definitions that might be extended to cover those code points in the > future. I don't see how this would really work in practice. Whether your data has unassigned code points or not, when the collations are updated to the next Unicode version, the collations will have a new version number, and so you need to run the refresh procedure in any case.