Message-ID: <07878ad1-d94d-5a92-565f-c0dfdea8b61b@enterprisedb.com>
Date: Wed, 16 Mar 2022 15:25:09 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.7.0
Subject: Re: ICU for global collation
Content-Language: en-US
To: Robert Haas <robertmhaas@gmail.com>
Cc: Julien Rouhaud <rjuju123@gmail.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>,
 Daniel Verite <daniel@manitou-mail.org>
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>
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
In-Reply-To: 
 <CA+Tgmobw227bwuHk6kwjriFQUofnZoAQhL1j3eYJyCcNO8u4MA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/07878ad1-d94d-5a92-565f-c0dfdea8b61b%40enterprisedb.com>
Precedence: bulk

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.