> I understand that in principle, but I don't see operating system > providers shipping a bunch of ICU versions to facilitate that. They > will usually ship one.
Yep. If you want the protection I've described, you can't depend on the OS copy of ICU. You need to have multiple ICU libraries that are named/installed such that you can load the specific version you want. It also means that you can have dependencies on versions of ICU that are no longer supported. (In my previous project, we were shipping 3 copies of the ICU library, going back to 2.x. Needless to say, we didn't add support for every drop of ICU.)
On 9/6/16 1:40 PM, Doug Doole wrote: > We carried the ICU version numbers around on our collation and locale > IDs (such as fr_FR%icu36) . The database would load multiple versions of > the ICU library so that something created with ICU 3.6 would always be > processed with ICU 3.6. This avoided the problems of trying to change > the rules on the user. (We'd always intended to provide tooling to allow > the user to move an existing object up to a newer version of ICU, but we > never got around to doing it.) In the code, this meant we were > explicitly calling the versioned API so that we could keep the calls > straight.
I understand that in principle, but I don't see operating system providers shipping a bunch of ICU versions to facilitate that. They will usually ship one.
-- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
