Re: Fix order of checking ICU options in initdb and create database - Mailing list pgsql-hackers

From Марина Полякова
Subject Re: Fix order of checking ICU options in initdb and create database
Date
Msg-id CA+Fhiey4P2CETrwzvtz+5rPQ9E=p6kEmLQAbwFLhsuWtMHPVDQ@mail.gmail.com
Whole thread Raw
In response to Re: Fix order of checking ICU options in initdb and create database  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: Fix order of checking ICU options in initdb and create database
List pgsql-hackers
сб, 19 нояб. 2022 г. в 15:51, Peter Eisentraut
<peter.eisentraut@enterprisedb.com>:
>
> On 19.11.22 13:12, Марина Полякова wrote:
> >> I'm not in favor of changing this.  The existing code intentionally
> >> tries to centralize the "ICU is not supported in this build" knowledge
> >> in few places.  Your patch tries to make this check early, but in the
> >> process adds more places where ICU support needs to be checked
> >> explicitly.  This increases the code size and also creates a future
> >> burden to maintain that level of checking.  I think building without ICU
> >> should be considered a marginal configuration at this point, so we don't
> >> need to go out of our way to create a perfect user experience for this
> >> configuration, as long as we check somewhere in the end.
> > Maybe this should be written in the documentation [1] or --with-icu
> > should be used by default? As a developer I usually check something
> > with the simplest configure run to make sure other options do not
> > affect the checked behaviour. And some other developers in our company
> > also use simple configure runs, without --with-icu etc.
>
> Well, this isn't a hard rule, just my opinion and where I see the world
> moving.  It's similar to --with-openssl and --with-lz4 etc.

Here is another set of proposed patches:

v2-0001-Fix-encoding-check-in-initdb-when-the-option-icu-.patch
Target: PG 15+
Fix encoding check in initdb when the option --icu-locale is not used:

$ initdb --encoding sql-ascii --locale-provider icu hoge
...
initdb: error: encoding mismatch
initdb: detail: The encoding you selected (SQL_ASCII) is not supported
with the ICU provider.
initdb: hint: Rerun initdb and either do not specify an encoding
explicitly, or choose a matching combination.

As with the previous version of this fix a side effect is that if ICU
locale is missed (or ICU is not supported in this build), the
provider, locales and encoding are reported before the error message:

$ initdb --locale-provider icu hoge
The files belonging to this database system will be owned by user "marina".
This user must also own the server process.

The database cluster will be initialized with this locale configuration:
  provider:    icu
  LC_COLLATE:  en_US.UTF-8
  LC_CTYPE:    en_US.UTF-8
  LC_MESSAGES: en_US.UTF-8
  LC_MONETARY: ru_RU.UTF-8
  LC_NUMERIC:  ru_RU.UTF-8
  LC_TIME:     ru_RU.UTF-8
The default database encoding has been set to "UTF8".
initdb: error: ICU locale must be specified

$ initdb --locale-provider icu --icu-locale en hoge
The files belonging to this database system will be owned by user "marina".
This user must also own the server process.

The database cluster will be initialized with this locale configuration:
  provider:    icu
  ICU locale:  en
  LC_COLLATE:  en_US.UTF-8
  LC_CTYPE:    en_US.UTF-8
  LC_MESSAGES: en_US.UTF-8
  LC_MONETARY: ru_RU.UTF-8
  LC_NUMERIC:  ru_RU.UTF-8
  LC_TIME:     ru_RU.UTF-8
The default database encoding has been set to "UTF8".
initdb: error: ICU is not supported in this build

v2-0002-doc-building-without-ICU-is-not-recommended.patch
Target: PG 15+
Fix the documentation that --without-icu is a marginal configuration.

v2-0003-Build-with-ICU-by-default.patch
Target: PG 16+
Build with ICU by default as already done for readline and zlib libraries.

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

Attachment

pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: How to *really* quit psql?
Next
From: Greg Stark
Date:
Subject: Re: How to *really* quit psql?