Re: ICU for global collation

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: m(dot)polyakova(at)postgrespro(dot)ru
Cc: pgsql-hackers(at)postgresql(dot)org, pryzby(at)telsasoft(dot)com, rjuju123(at)gmail(dot)com, daniel(at)manitou-mail(dot)org, AndrewBille(at)gmail(dot)com, michael(at)paquier(dot)xyz, peter(dot)eisentraut(at)enterprisedb(dot)com
Subject: Re: ICU for global collation
Date: 2022-09-15 06:52:10
Message-ID: 20220915.155210.529619933474389138.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Wed, 14 Sep 2022 17:19:34 +0300, Marina Polyakova <m(dot)polyakova(at)postgrespro(dot)ru> wrote in
> Hello!
>
> I was surprised that it is allowed to create clusters/databases where
> the default ICU collations do not actually work due to unsupported
> encodings:
>
> $ initdb --encoding SQL_ASCII --locale-provider icu --icu-locale en-US
> -D data &&
> pg_ctl -D data -l logfile start &&
> psql -c "SELECT 'a' < 'b'" template1
> ...
> waiting for server to start.... done
> server started
> ERROR: encoding "SQL_ASCII" not supported by ICU

Indeed. If I did the following, the direction of the patch looks fine
to me.

If I executed initdb as follows, I would be told to specify
--icu-locale option.

> $ initdb --encoding sql-ascii --locale-provider icu hoge
> ...
> initdb: error: ICU locale must be specified

However, when I reran the command, it complains about incompatible
encoding this time. I think it's more user-friendly to check for the
encoding compatibility before the check for missing --icu-locale
option.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2022-09-15 07:09:44 Re: New strategies for freezing, advancing relfrozenxid early
Previous Message Jaime Casanova 2022-09-15 06:26:15 Re: START_REPLICATION SLOT causing a crash in an assert build