Re: Fix order of checking ICU options in initdb and create database

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Fix order of checking ICU options in initdb and create database
Дата
Msg-id 205d3e3a-f726-be6b-c3bb-18333f432504@enterprisedb.com
обсуждение исходный текст
Ответ на Fix order of checking ICU options in initdb and create database  (Marina Polyakova <m.polyakova@postgrespro.ru>)
Ответы Re: Fix order of checking ICU options in initdb and create database  (Марина Полякова <polyakova.marina69@gmail.com>)
Список pgsql-hackers
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.




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Fix order of checking ICU options in initdb and create database
Следующее
От: David Geier
Дата:
Сообщение: Re: Assertion failure with barriers in parallel hash join