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>, Robert Haas <robertmhaas@gmail.com>

Cc: pgsql-hackers@postgresql.org

Date: 2023-10-11T07:53:39Z

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 Wed, 2023-10-11 at 08:51 +0200, Peter Eisentraut wrote:
> 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.

Even with a version number, we don't provide a great reresh procedure
or document how it should be done. In practice, avoiding unassigned
code points might mitigate some kinds of problems, especially for glibc
which has a very coarse version number.

In any case, a CHECK constraint to avoid unassigned code points has
utility to be forward-compatible with normalization, and also might
just be a good sanity check.

Regards,
	Jeff Davis