Collegues,
PostgreSQL 10 when build with --with-icu requires ICU 4.6 and above.
(because it searches for libicu using pkgconfig, and pgkconfig support
significantly changed in ICU version 4.6)
However, there are some reasons to build PostgreSQL with older versions
of ICU.
For instance such Linux distributions as RHEL 6 ships ICU 4.2, and SLES
11 also ships older ICU. Sometimes, it is not feasible to compile newer
ICU from sources on the servers with these (and derived) distributions.
It is possible to compile PostgreSQL 10 with these versions of ICU
by specifying ICU_CFLAGS and ICU_LIBS explicitely.
However, backend startup fails with errors on some Spanish and
Singalese locales.
It turns out, that PostgreSQL enumerates collations for all ICU locales
and passes it into uloc_toLanguageTag function with strict argument of
this function set to TRUE. But for some locales
(es*@collation=tradtiional, si*@collation=dictionary) only call with
strict=FALSE succeeds in ICU 4.2. In newer versions of ICU all locales
can be resolved with strict=TRUE.
ICU docs state that if strict=FALSE, some locale fields can be
incomplete.
What solition is better:
1. Just skip locale/collation combinations which cannot be resolved
with strict=TRUE and issue warning instead of error if
uloc_toLanguageTag fails on some locale.
It would cause some ICU collations be missiong from the databases
running on the systems with old ICU.
2. If we see ICU version earlier than 4.6, pass strict=FALSE to
ucol_toLanguageTag. It would cause databases on such systems use
fallback collation sequence for these collations.
Personally I prefer first solition, because I doubt that any of my
users would ever need Singalese collation, and probably they can
survive without traditional Spanish too.
-- Victor Wagner <vitus@wagner.pp.ru>