On Tue, 18 Mar 2025 08:53:56 -0700 Jeff Davis <pg...@j-davis.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.1742055...@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
