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
|
Список | 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 по дате отправления: