Horton
Menu

Re: ICU for global collation

Marina Polyakova <m.polyakova@postgrespro.ru>

View thread
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
Date: 2022-09-13T15:51:39Z
Lists: pgsql-hackers 
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

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add CHECK_FOR_INTERRUPTS while restoring changes during decoding.

  2. Improve ICU option handling in CREATE DATABASE

  3. Don't allow creation of database with ICU locale with unsupported encoding

  4. Make locale option behavior more consistent

  5. pg_dump: Dump colliculocale

  6. Remove further unwanted linker flags from perl_embed_ldflags

  7. Doc: document possible need to raise kernel's somaxconn limit.

  8. Reduce warnings with -Wshadow=compatible-local builds

  9. Remove redundant spaces in _outA_Expr() output

  10. Fix outdated --help message for postgres -f

  11. pg_upgrade: Fix version comparison for global ICU support

  12. Silence -Wmaybe-uninitialized compiler warning in dbcommands.c.

  13. Add option to use ICU as global locale provider

  14. DefineCollation() code cleanup

  15. Change collate and ctype fields to type text

  16. Call pg_newlocale_from_collation() also with default collation

  17. Use libc version as a collation version on glibc systems.

  18. Silence -Wmaybe-uninitialized compiler warnings in dbcommands.c.

  19. Make LC_COLLATE and LC_CTYPE database-level settings. Collation and