чт, 17 нояб. 2022 г. в 09:58, Peter Eisentraut
<peter.eisentraut@enterprisedb.com>:
>
> On 29.10.22 13:33, Marina Polyakova wrote:
> > 2. initdb/create database report problems with the ICU locale/encoding
> > although they may already report that ICU is not supported in this build:
> >
> > 2.1.
> >
> > $ initdb --locale-provider icu hoge
> > ...
> > initdb: error: ICU locale must be specified
> >
> > $ initdb --locale-provider icu --icu-locale en-US hoge
> > ...
> > initdb: error: ICU is not supported in this build
> >
> > $ createdb --locale-provider icu hoge
> > createdb: error: database creation failed: ERROR: ICU locale must be
> > specified
> >
> > $ createdb --locale-provider icu --icu-locale en-US hoge
> > createdb: error: database creation failed: ERROR: ICU is not supported
> > in this build
>
> 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.
[1] https://www.postgresql.org/docs/15/install-procedure.html
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
