MIME-Version: 1.0
Date: Tue, 13 Sep 2022 18:51:39 +0300
From: Marina Polyakova <m.polyakova@postgrespro.ru>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>, pgsql-hackers@postgresql.org,
 Julien Rouhaud <rjuju123@gmail.com>, Daniel Verite
 <daniel@manitou-mail.org>, AndrewBille@gmail.com, michael@paquier.xyz
Subject: Re: ICU for global collation
In-Reply-To: <1f86f120-7b02-68f6-a434-132d054afe33@enterprisedb.com>
References: <20220628013205.GH19662@telsasoft.com>
 <f385ba25e7f8be427b8c582e5cca7d79@postgrespro.ru>
 <7d74b2d7-7fc6-f55b-3f77-c0e05569b64e@enterprisedb.com>
 <YwRUn4J8+uqlyUYQ@paquier.xyz>
 <7ad26354e75259f59c4a6c6997b8ee32@postgrespro.ru>
 <YwWrVEDpLNGFA4Mq@paquier.xyz> <20220824085923.jro5ao2m5b4mdll5@jrouhaud>
 <13468bee-a5b4-65aa-932c-c12584f4458d@enterprisedb.com>
 <Yw4KoBm1mS+2xzIj@paquier.xyz>
 <7c99c132dc9c0ac630e0127f032ac480@postgrespro.ru>
 <20220909164625.GN31833@telsasoft.com>
 <60facfef2a8d54b227500260e86d823e@postgrespro.ru>
 <1f86f120-7b02-68f6-a434-132d054afe33@enterprisedb.com>
User-Agent: Roundcube Webmail/1.4.11
Message-ID: <38d2aac40a991b20adf032e509c6eff5@postgrespro.ru>
Organization: Postgres Professional
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/38d2aac40a991b20adf032e509c6eff5%40postgrespro.ru>
Precedence: bulk

On 2022-09-13 15:41, Peter Eisentraut wrote:
> On 13.09.22 07:34, Marina Polyakova wrote:
>> I agree with you that it is more comfortable and more similar to what 
>> has already been done in initdb. IMO it would be easier to do it like 
>> this:
>> 
>> diff --git a/src/bin/scripts/createdb.c b/src/bin/scripts/createdb.c
>> index 
>> e523e58b2189275dc603a06324a2f28b0f49d8b7..a1482df3d981a680dd3322052e7c03ddacc8dc26 
>> 100644
>> --- a/src/bin/scripts/createdb.c
>> +++ b/src/bin/scripts/createdb.c
>> @@ -161,12 +161,10 @@ main(int argc, char *argv[])
>> 
>>       if (locale)
>>       {
>> -        if (lc_ctype)
>> -            pg_fatal("only one of --locale and --lc-ctype can be 
>> specified");
>> -        if (lc_collate)
>> -            pg_fatal("only one of --locale and --lc-collate can be 
>> specified");
>> -        lc_ctype = locale;
>> -        lc_collate = locale;
>> +        if (!lc_ctype)
>> +            lc_ctype = locale;
>> +        if (!lc_collate)
>> +            lc_collate = locale;
>>       }
>> 
>>       if (encoding)
> 
> done that way

Thank you!

>>> BTW it's somewhat crummy that it uses a string comparison, so if you
>>> write "UTF8" without a dash, it says this; it took me a few minutes 
>>> to
>>> see the difference...
>>> 
>>> postgres=# create database a LC_COLLATE "en_US.UTF8" LC_CTYPE
>>> "en_US.UTF8" LOCALE "en_US.UTF8";
>>> ERROR:  new collation (en_US.UTF8) is incompatible with the collation
>>> of the template database (en_US.UTF-8)
>> 
>> Perhaps we could check the locale itself with the function 
>> normalize_libc_locale_name (collationcmds.c). But ISTM that the 
>> current check is a safety net in case the function 
>> pg_get_encoding_from_locale (chklocale.c) returns -1 or 
>> PG_SQL_ASCII...
> 
> This is not new behavior in PG15, is it?

No, it has always existed [1] AFAICS..

[1] 
https://github.com/postgres/postgres/commit/61d967498802ab86d8897cb3c61740d7e9d712f6

-- 
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company