Re: Update Unicode data to Unicode 16.0.0

On Tue, 18 Mar 2025 08:53:56 -0700
Jeff Davis <pgsql(at)j-davis(dot)com> wrote:

> What do you think of Tom's argument that waiting to update Unicode is
> what creates the problem in the first place?
>
> "by then they might well have instances of the newly-assigned code
> points in their database"[1]
>
> [1]
> https://www.postgresql.org/message-id/3481161.1742055336@sss.pgh.pa.us

Waiting to update Unicode is not what creates the problem, as long as
we support in-place major upgrades without rebuilding indexes.

It seems that we think that it's really uncommon to make indexes on
timezone data. We think that breaking primary keys must definitely be
avoided. We think case-insensitive indexes are probably uncommon, so as
long as its "rare" we can let them break.

I'm not asking for an extreme definition of "IMMUTABLE" but I'd be
very happy with a GUC "data_safety=radical_like_jeremy" where Postgres
simply won't start if the control file says it was from a different
operating system or architecture or ICU/glibc collation version. I can
disable the GUC (like a maintenance mode) to rebuild my indexes and
update my collation versions, and ideally this GUC would also mean that
indexes simply aren't allowed to be created on functions that might
change within the guarantees that are made. (And range-based partitions
can't use them, and FDWs can't rely on them for query planning, etc.)

I get that we don't want to break stuff people are currently doing -
but I think there are a bunch of people who would be happy with an
option to reduce functionality going forward in exchange for clearly
defined behavior. I just don't want to have to think about this on
behalf of all my Postgres users.

-Jeremy