Jeff Davis wrote: > As I replied in that subthread, that creates a worse problem: if you > only change the provider when the locale is C, then what about when the > locale is *not* C? > > export LANG=en_US.UTF-8 > initdb -D data --locale=fr_FR.UTF-8 > ... > provider: icu > ICU locale: en-US
What you're proposing with the 0003 patch still applies. In the above case I think we would end up with: provider=icu ICU locale=fr-FR lc_collate=fr_FR.UTF-8 lc_lctype=fr_FR.UTF-8 which is reasonable. In the following cases we would initialize a libc cluster instead of an ICU cluster: - initdb --locale=C - initdb --locale=POSIX - LANG=C initdb - LANG=C.UTF-8 initdb - LANG=POSIX initdb - ... possibly other locales that we find are unsuitable for ICU That is, the rule "ICU by default" really means "ICU unless the locale that we're being passed or getting from the environment has semantics that ICU does not provide but we know libc provides, in which case we fall back to libc". The user who wants ICU imperatively should invoke --icu-locale=something or --locale=something --locale-provider=icu in which case we should not fallback to libc. We still have to determine lc_collate and lc_ctype either from the environment or from the locale argument (I think we should favor the environment), except if the user specifies --lc-collate=... lc-ctype=... Best regards, -- Daniel Vérité https://postgresql.verite.pro/ Twitter: @DanielVerite
