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 <vi...@wagner.pp.ru> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers