From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Julien Rouhaud <rjuju123@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Cc: Daniel Verite <daniel@manitou-mail.org>
Subject: Re: ICU for global collation
Date: Wed, 16 Mar 2022 15:25:09 +0100
Message-ID: <07878ad1-d94d-5a92-565f-c0dfdea8b61b@enterprisedb.com> (raw)
In-Reply-To: <CA+Tgmobw227bwuHk6kwjriFQUofnZoAQhL1j3eYJyCcNO8u4MA@mail.gmail.com>
References: <a6f807c2-2d11-2cf6-a524-cfbec56e7d5b@enterprisedb.com>
<20220118040246.dewl5pain2gkv2iv@jrouhaud>
<171c5f7c-43ee-dbe9-31f9-5e3eb06a54cf@enterprisedb.com>
<e381e36c-c7a2-2ec0-dbb4-da1dab3f0941@enterprisedb.com>
<20220121135119.ywszwl4353v5dzh5@jrouhaud>
<e2061949-f731-fd60-8b0b-3bae75095b4f@enterprisedb.com>
<20220121161331.xn7fhtfg5j2ucilb@jrouhaud>
<87e93704-b7f7-71f6-161d-8713e6334ed3@enterprisedb.com>
<704405ed-f1fa-d2a7-b9f9-48a07fb45648@enterprisedb.com>
<96a50803-72ba-8eec-948a-d87608ac15a0@enterprisedb.com>
<20220305083830.lpz3k3yku5lmm5xs@jrouhaud>
<42ce518d-1426-fa9e-1fcc-de090cd55331@enterprisedb.com>
<CA+Tgmoaqb+3nAMgHVoSWeHu-58hBzfDevqmZOy2-HuDZJgkCzQ@mail.gmail.com>
<ecac910c-d3d3-1d39-1040-2021f3551c69@enterprisedb.com>
<CA+Tgmobw227bwuHk6kwjriFQUofnZoAQhL1j3eYJyCcNO8u4MA@mail.gmail.com>
On 15.03.22 18:28, Robert Haas wrote:
> On Tue, Mar 15, 2022 at 12:58 PM Peter Eisentraut
> <peter.eisentraut@enterprisedb.com> wrote:
>> On 14.03.22 19:57, Robert Haas wrote:
>>> 1. What will happen if I set the ICU collation to something that
>>> doesn't match the libc collation? How bad are the consequences?
>>
>> These are unrelated, so there are no consequences.
>
> Can you please elaborate on this?
The code that is aware of ICU generally works like this:
if (locale_provider == ICU)
result = call ICU code
else
result = call libc code
return result
However, there is code out there, both within PostgreSQL itself and in
extensions, that does not do that yet. Ideally, we would eventually
change all that over, but it's not happening now. So we ought to
preserve the ability to set the libc to keep that legacy code working
for now.
This legacy code by definition doesn't know about ICU, so it doesn't
care whether the ICU setting "matches" the libc setting or anything like
that. It will just do its thing depending on its own setting.
The only consequence of settings that don't match is that the different
pieces of code behave semantically inconsistently (e.g., some routine
thinks the data is Greek and other code thinks the data is French). But
that's up to the user to set correctly. And the actual scenarios where
you can actually do anything semantically relevant this way are very
limited.
A second point is that the LC_CTYPE setting tells other parts of libc
what the current encoding is. This affects gettext for example. So you
need to set this to something sensible even if you don't use libc locale
routines otherwise.
>>> 2. If I want to avoid a mismatch between the two, then I will need a
>>> way to figure out which libc collation corresponds to a given ICU
>>> collation. How do I do that?
>>
>> You can specify the same name for both.
>
> Hmm. If every name were valid in both systems, I don't think you'd be
> proposing two fields.
Earlier versions of this patch and predecessor patches indeed had common
fields. But in fact the two systems accept different values if you want
to delve into the advanced features. But for basic usage something like
"en_US" will work for both.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: peter.eisentraut@enterprisedb.com, robertmhaas@gmail.com, rjuju123@gmail.com, daniel@manitou-mail.org
Subject: Re: ICU for global collation
In-Reply-To: <07878ad1-d94d-5a92-565f-c0dfdea8b61b@enterprisedb.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox