Re: [HACKERS] Re: ICU collation variant keywords and pg_collationentries (Was: [BUGS] Crash report for some ICU-52 (debian8) COLLATE andwork_mem values)

On Tue, Aug 22, 2017 at 4:58 AM, Daniel Verite <daniel@manitou-mail.org> wrote:
> For the record, attached are the collname that initdb now creates
> in pg_collation, when compiled successively with all current
> versions of ICU (49 to 59), versus what 10beta2 did.
>
> There are still a few names that get dropped along the ICU
> upgrade path, but now they look like isolated cases.

Even though ICU initdb collations are now as stable as possible, which
is great, I still think that Tom had it right about pg_upgrade: Long
term, it would be preferable if we also did a CREATE COLLATION when
initdb stable collations/base ICU locales go away for pg_upgrade. We
should do such a CREATE COLLATION if and only if that makes the
upgrade succeed where it would otherwise fail. This wouldn't be a
substitute for initdb collation name stability. It would work
alongside it.

This makes sense with ICU. The equivalent of a user-defined CREATE
COLLATION with an old country code may continue to work acceptably
because ICU/CLDR supports aliasing, and/or doesn't actually care that
a deleted country tag (e.g. the one for Serbia and Montenegro [1]) was
used. It'll still interpret Serbian as Serbian (sr-*), regardless of
what country code may also appear, even if the country code is not
just obsolete, but entirely bogus.

Events like the dissolution of countries are rare enough that that
extra assurance is just a nice-to-have, though.

[1] https://en.wikipedia.org/wiki/ISO_3166-2:CS
-- 
Peter Geoghegan