On 6/6/23 15:18, Jeff Davis wrote:
> On Tue, 2023-06-06 at 15:09 +0200, Daniel Verite wrote:
>> FWIW I don't quite see how 0001 improve things or what problem it's
>> trying to solve.
>
> The word "locale" is generic, so we need to make LOCALE/--locale apply
> to whatever provider is being used. If "locale" only applies to libc,
> using ICU will always be confusing and never be on the same level as
> libc, let alone the preferred provider.
Agree 100%
> The locale "C" is a special case, documented as a non-locale. So, if
> LOCALE/--locale apply to ICU, then either ICU needs to handle locale
> "C" in the expected way (v8 patch series); or when we see locale "C" we
> need to somehow change the provider into something that can handle it
> (v6 patch series changes it to the "none" provider).
+1 to the latter approach
> Please let me know if you disagree with the goal or the reasoning here.
> If so, please explain where you think we should end up, because the
> status quo does not seem great to me.
also +1
>> 0001 creates exceptions throughout the code so that when an ICU
>> collation has a locale name "C" or "POSIX" then it does not behave
>> like an ICU collation, even though pg_collation.collprovider='i'
>> To me it's neither desirable nor necessary that a collation that
>> has collprovider='i' is diverted to non-ICU semantics.
>
> It's not very principled, but it matches what libc does.
Makes sense to me
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com