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
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 |