On Wed, Oct 7, 2015 at 8:06 PM, Thomas Munro
<thomas.munro@enterprisedb.com> 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