Re: Collation version tracking for macOS

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Jeremy Schneider <schneider(at)ardentperf(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, "Nasby, Jim" <nasbyj(at)amazon(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Collation version tracking for macOS
Date: 2022-12-05 15:45:26
Message-ID: CA+TgmoZ_qNa-GXAPcdRexF=JtCmVvo53wnEVzEBgoVaz3hspbQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Dec 4, 2022 at 10:12 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> My tentative votes are:
>
> 1. I think we should seriously consider provider = ICU63. I still
> think search-by-collversion is a little too magical, even though it
> clearly can be made to work. Of the non-magical systems, I think
> encoding the choice of library into the provider name would avoid the
> need to add a second confusing "X_version" concept alongside our
> existing "X_version" columns in catalogues and DDL syntax, while still
> making it super clear what is going on. This would include adding DDL
> commands so you can do ALTER DATABASE/COLLATION ... PROVIDER = ICU63
> to make warnings go way.

+1. I wouldn't lose any sleep if we picked a different non-magical
option, but I think this is probably my favorite of the
explicit-library-version options (though it is close) and I like it
better than search-by-collversion.

(It's possible that I'm wrong to like it better, but I do.)

> 2. I think we should ignore minor versions for now (other than
> reporting them in the relevant introspection functions), but not make
> any choices that would prevent us from changing our mind about that in
> a later release. For example, having two levels of specificity ICU
> and ICU68 in the libver-in-provider-name design wouldn't preclude us
> from adding support for ICU68_2 later

+1.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2022-12-05 15:47:49 Re: Error-safe user functions
Previous Message Thom Brown 2022-12-05 15:44:59 Re: [PoC] Reducing planning time when tables have many partitions