Re: collation-related loose ends before beta2

Поиск
Список
Период
Сортировка
От Jonathan S. Katz
Тема Re: collation-related loose ends before beta2
Дата
Msg-id 5a9840b3-36d9-6485-6a98-3cb138a26afd@postgresql.org
обсуждение исходный текст
Ответ на collation-related loose ends before beta2  (Jeff Davis <pgsql@j-davis.com>)
Список 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]

(Building...)

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.

Thanks,

Jonathan


Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Nathan Bossart
Дата:
Сообщение: Re: allow granting CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX
Следующее
От: Nathan Bossart
Дата:
Сообщение: Re: add non-option reordering to in-tree getopt_long