Re: collation-related loose ends before beta2

From: "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>
To: Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org
Cc: Daniel Verite <daniel(at)manitou-mail(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Joe Conway <mail(at)joeconway(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Subject: Re: collation-related loose ends before beta2
Date: 2023-06-21 17:17:33
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 6/20/23 5:02 AM, Jeff Davis wrote:
> Status on collation loose ends:
> 1. There's an open item "Switch to ICU for 17". It's a little bit
> confusing exactly what that means, and the CF entry refers to two
> items, one of which is the build-time default to --with-icu. As far as
> I know, building with ICU by default is a settled issue with no
> objections. The second issue is the initdb default, which is covered by
> the other open item. So I will just close that open item unless someone
> thinks I'm missing something.

[RMT Hat]

No objections. The RMT had interpreted this as "Punt on making ICU the
building default to v17" but it seems the consensus is to continue to
leave it in as the default for v16.

> 2. Open item about the unfriendly rules for choosing an ICU locale at
> initdb time. Tom, Robert, and Daniel Verite have expressed concerns
> (and at least one objection) to initdb defaulting to icu for --locale-
> provider. Some of the problems have been addressed, but the issue about
> C and C.UTF-8 locales is not settled. Even if it were settled I'm not
> sure we'd have a clear consensus on all the details. I don't think this
> should proceed to beta2 in this state, so I intend to revert back to
> libc as the default for initdb. [ I believe we do have a general
> consensus that ICU is better, but we can signal it other ways: through
> documentation, packaging, etc. ]

[Personal hat]


I do think this raises a good point: it's really the packaging that will
guide what users are using for v16. I don't know if we want to
discuss/poll the packagers to see what they are thinking about this?

> 3. The ICU conversion from "C" to "en-US-u-va-posix": cut out this code
> (it was a small part of a larger change). It's only purpose was
> consistency between ICU versions, and nobody liked it. It's only here
> right now to avoid test failures due to an order-of-commits issue; but
> if the initdb default goes back to libc it won't matter and I can
> remove it.
> 4. icu_validation_level WARNING or ERROR: right now an invalid ICU
> locale raises a WARNING, but Peter Eisentraut would prefer an ERROR.
> I'm still inclined to leave it as a WARNING for one release and
> increase it to ERROR later. But if the default collation provider goes
> back to libc, the risk of ICU validation errors goes way down, so I
> don't object if Peter would like to change it back to an ERROR.

[Personal hat]

I'd be inclined for "WARNING" until getting a sense of what packagers
who do an initdb as part of the installation process decide what
collation provider they're going to use.



In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2023-06-21 17:56:24 Re: add non-option reordering to in-tree getopt_long
Previous Message Nathan Bossart 2023-06-21 17:16:24 Re: allow granting CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX