Horton
Menu

Re: ICU for global collation

Marina Polyakova <m.polyakova@postgrespro.ru>

View thread
From: Marina Polyakova <m.polyakova@postgrespro.ru>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: pgsql-hackers@postgresql.org, pryzby@telsasoft.com, rjuju123@gmail.com, daniel@manitou-mail.org, AndrewBille@gmail.com, michael@paquier.xyz, peter.eisentraut@enterprisedb.com
Date: 2022-09-17T07:05:32Z
Lists: pgsql-hackers 
On 2022-09-16 11:11, Kyotaro Horiguchi wrote:
> At Fri, 16 Sep 2022 09:49:28 +0300, Marina Polyakova
> <m.polyakova@postgrespro.ru> wrote in
>> In continuation of options check: AFAICS the following checks in
>> initdb
>> 
>> 	if (locale_provider == COLLPROVIDER_ICU)
>> 	{
>> 		if (!icu_locale)
>> 			pg_fatal("ICU locale must be specified");
>> 
>> 		/*
>> 		 * In supported builds, the ICU locale ID will be checked by the
>> 		 * backend during post-bootstrap initialization.
>> 		 */
>> #ifndef USE_ICU
>> 		pg_fatal("ICU is not supported in this build");
>> #endif
>> 	}
>> 
>> are executed approximately when they are executed in create database
>> after getting all the necessary data from the template database:
> 
> initdb doesn't work that way, but anyway, I realized that I am
> proposing to move that code in setlocales() to the caller function as
> the result. I don't think setlocales() is the place for the code
> because icu locale has no business with what the function does.  That
> being said there's no obvious reason we *need* to move the code out to
> its caller.

Excuse me, but could you explain your last sentence in more detail? I 
read that this code is not for setlocales and then - that it should not 
moved from here, so I'm confused...

> +					 errmsg("encoding \"%s\" is not supported with ICU provider",
> 
> +		pg_log_error("encoding \"%s\" is not supported with ICU provider",
> +					 pg_encoding_to_char(encodingid));
> 
> I might be wrong, but the messages look wrong to me.  The alternatives
> below might work.
> 
> "encoding \"%s\" is not supported by ICU"
> "encoding \"%s\" cannot be used for/with ICU locales"

The message indicates that the selected encoding cannot be used with the 
ICU provider because it does not support it. But if the text of the 
message becomes better and clearer, I will only be glad.

> +		pg_log_error_hint("Rerun %s and choose a matching combination.",
> +						  progname);
> 
> This doesn't seem to provide users with useful information.

It was commited in more verbose form:

pg_log_error_hint("Rerun %s and either do not specify an encoding 
explicitly, "
				  "or choose a matching combination.",

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