Re: Update Unicode data to Unicode 16.0.0
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Jeremy Schneider <schneider@ardentperf.com>,
Nathan Bossart <nathandbossart@gmail.com>,
Peter Eisentraut <peter@eisentraut.org>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-03-17T18:04:08Z
Lists: pgsql-hackers
Jeff Davis <pgsql@j-davis.com> writes: > That was discussed a few times, but: > (a) That doesn't exactly solve the problem, because people still need > indexes on LOWER() or CASEFOLD(); and > (b) If we change IMMUTABLE to mean "returns the same results on every > platform for all time", that would be too strict for many purposes, > like the planner doing constant folding. Yeah. Not only would the set of functions meeting such a standard be vanishingly small, but so would the set of use-cases. What we need is some sort of understanding that "this is okay to use in indexes", "this is okay to constant-fold when planning", etc. Maybe it's less about "is it okay to just assume this" and more about "can we devise a method for figuring out when we have to reindex, replan, etc". We've got bits of that in our collation versioning infrastructure, but that doesn't cover every source of infrequently-mutating behavior. > I have been thinking about ways we can express the right dependencies, > and I may be making some proposals along those lines. I await a proposal with interest. regards, tom lane
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