Re: Collation version tracking for macOS

Jeremy Schneider <schneider@ardentperf.com>

From: Jeremy Schneider <schneider@ardentperf.com>

To: Thomas Munro <thomas.munro@gmail.com>

Cc: Peter Geoghegan <pg@bowt.ie>, Jim Nasby <nasbyj@amazon.com>, Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, pgsql-hackers <pgsql-hackers@postgresql.org>

Date: 2022-06-09T05:24:49Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Fix copy&paste typo in comment
- 402388946fb3 17.0 cited

> On Jun 8, 2022, at 03:19, Thomas Munro <thomas.munro@gmail.com> wrote:
> 
> On Wed, Jun 8, 2022 at 12:23 PM Peter Geoghegan <pg@bowt.ie> wrote:
>> ISTM that there are two mostly-distinct questions here:
>> 
>> 1. How do we link to multiple versions of ICU at the same time, in a
>> way that is going to work smoothly on mainstream platforms?
>> 
> Yeah.  Well I couldn't resist doing some (very!) experimental hacking.
> See attached. 

Even if PG supports two versions of ICU, how does someone actually go about removing every dependency on the old version and replacing it with the new? Can it be done without downtime? Can it be done without modifying a running application? Avoiding “collate” clauses on SQL statements requires working behind the scenes with defaults and indexes and partitions and constraints and everything else. I’m having a hard time coming up with a way this would be possible in practice, with all the places collations can show up.

Is the idea of “alter database” to change the default collation even realistic?

I’m having a bit of trouble picturing what the end game is here

-Jeremy

Sent from my TI-83