On Wed, Oct 7, 2015 at 8:06 PM, Thomas Munro <thomas.munro@xxxxxxxxxxxxxxxx> wrote: >> I think we should bite the bullet and adopt ICU, without abandoning >> support for OS locales for users that really need it (certainly, many >> will need it initially when using pg_upgrade to get on to the first >> version that happens to have ICU support). I don't like suggesting a >> solution that I myself am unlikely to find the time to work on, but in >> the long run that's the only sensible approach IMV. > > How would you handle changes in ICU's collation definitions? ICU provides an API for collation versioning because of these kinds of issues with indexes: http://userguide.icu-project.org/collation/architecture#TOC-Versioning There are specifications of collations used by ICU that originate from the Unicode CLDR Project: http://cldr.unicode.org/ Basically, you prevent this kind of thing from ever happening in the first place by making versioning explicit, and putting it under the direct control of Postgres. I think a bunch of well regarded database systems have used ICU for many years, including DB2, for example. I think it's possible to arrange it so that the collations simply never go away, but if that does happen (or if you decide that the changes to a collation matter for cultural or correctness reasons) then you can at least detect the change and recover from it reliably. ICU has some other really nice features, too, but that's another discussion. -- Regards, Peter Geoghegan -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
