Re: [18] Policy on IMMUTABLE functions and Unicode updates

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Jeremy Schneider <schneider(at)ardentperf(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Cc: Daniel Verite <daniel(at)manitou-mail(dot)org>, Noah Misch <noah(at)leadboat(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [18] Policy on IMMUTABLE functions and Unicode updates
Date: 2024-07-24 17:35:38
Message-ID: 1b5ec4c8e43376346cde1ecc18516a0bbe92140a.camel@j-davis.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2024-07-23 at 06:31 -0600, Jeremy Schneider wrote:
> Other RDBMS are very careful not to corrupt databases, afaik
> including function based indexes, by changing Unicode. I’m not aware
> of any other RDBMS that updates Unicode versions in place; instead
> they support multiple Unicode versions and do not drop the old ones.

I'm curious about the details of what other RDBMSs do.

Let's simplify and say that there's one database-wide collation at
version 1, and the application doesn't use any COLLATE clause or other
specifications for queries or DDL.

Then, version 2 of that collation becomes available. When a query comes
into the database, which version of the collation does it use, 1 or 2?
If it uses the latest available (version 2), then all the old indexes
are effectively useless.

So I suppose there's some kind of migration process where you
rebuild/fix objects to use the new collation, and when that's done then
you change the default so that queries use version 2. How does all that
work?

Regards,
Jeff Davis

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-07-24 17:36:45 Re: Fixing backslash dot for COPY FROM...CSV
Previous Message Laurenz Albe 2024-07-24 17:02:11 Re: proposal: schema variables