Horton

Thread

Commits

  1. initdb: change default --locale-provider back to libc.

  1. collation-related loose ends before beta2

    Jeff Davis <pgsql@j-davis.com> — 2023-06-20T09:02:36Z

    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.

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. ]

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.

Regards,
	Jeff Davis

  2. Re: collation-related loose ends before beta2

    Tom Lane <tgl@sss.pgh.pa.us> — 2023-06-20T16:16:04Z

    Jeff Davis <pgsql@j-davis.com> writes:
> Status on collation loose ends:

This all sounds good to me.

			regards, tom lane

  3. Re: collation-related loose ends before beta2

    Jeff Davis <pgsql@j-davis.com> — 2023-06-20T20:46:29Z

    On Tue, 2023-06-20 at 12:16 -0400, Tom Lane wrote:
> Jeff Davis <pgsql@j-davis.com> writes:
> > Status on collation loose ends:
> 
> This all sounds good to me.

Patches attached.

0001 also removes the code to get a default locale when ICU is being
used, because that was a part of the same commit that changed the
default provider to be ICU and I don't see a lot of value in keeping
just that part.

I'm planning to commit something similar to the attached patches
tomorrow (Wednesday) unless I get more input.

Regards,
	Jeff Davis

  4. Re: collation-related loose ends before beta2

    Jonathan S. Katz <jkatz@postgresql.org> — 2023-06-21T17:17:33Z

    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