Re: Fix order of checking ICU options in initdb and create database
От | Марина Полякова |
---|---|
Тема | Re: Fix order of checking ICU options in initdb and create database |
Дата | |
Msg-id | CA+Fhiey4P2CETrwzvtz+5rPQ9E=p6kEmLQAbwFLhsuWtMHPVDQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Fix order of checking ICU options in initdb and create database (Peter Eisentraut <peter.eisentraut@enterprisedb.com>) |
Ответы |
Re: Fix order of checking ICU options in initdb and create database
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: