Re: Update Unicode data to Unicode 16.0.0
Jeff Davis <pgsql@j-davis.com>
From: Jeff Davis <pgsql@j-davis.com>
To: Peter Eisentraut <peter@eisentraut.org>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-02-05T21:47:19Z
Lists: pgsql-hackers
Attachments
- v1-0001-Add-pg_upgrade-check-for-Unicode-dependent-relati.patch (text/x-patch) patch v1-0001
On Mon, 2024-11-11 at 07:27 +0100, Peter Eisentraut wrote: > Here is the patch to update the Unicode data to version 16.0.0. > > Normally, this would have been routine, but a few months ago there > was > some debate about how this should be handled. [0] AFAICT, the > consensus > was to go ahead with it, but I just wanted to notify it here to be > clear. We discussed $SUBJECT at the Developer Meeting before FOSDEM. Those people who were most concerned about the Unicode updates on the list were not present, so I don't consider the discussion to be binding. But the attendees present agreed that: (a) we should not block the update to Unicode indefinitely; and (b) we should make reasonable attempts to mitigate potential problems. One idea for (b) resurfaced, which was to make a best-effort check at pg_upgrade time for affected indexes. The check would not be bulletproof, because we can't catch dependencies that are hidden inside SPI (e.g. a plpgsql function that calls LOWER()), but it would catch most potential problems. Patch attached. A few notes: * The dependency entries don't exist because LOWER(), etc., are system objects (pinned); so it queries the indexprs, indpreds, partexprs, and conbin. * The query is large and perhaps too clever, but it seems to work. I tried to add inline comments to the SQL, and pgindent had its own ideas about how to format them -- suggestions welcome. * We haven't actually done the Unicode update yet, so it will notice that the PG17 and PG18 Unicode versions are the same, and return early. Either apply on top of the Unicode update patch, or comment out the early return for testing. * It emits a warning rather than an error, so you need to specify pg_upgrade with "-r" to see the output file. * I didn't adapt the query to run on pre-17 versions, even though it could find some potential problem cases (like an index on NORMALIZE()). I can add that if someone thinks it's worthwhile. Regards, Jeff Davis
Commits
-
pg_upgrade: Fix memory leak in check_for_unicode_update().
- de48056ec7d2 18.0 landed
-
pg_upgrade check for Unicode-dependent relations.
- b81ffa13e356 18.0 landed
-
Update Unicode data to Unicode 16.0.0
- 82a46cca99fa 18.0 landed