On 9/8/16 11:16 AM, Tom Lane wrote: > This is a problem, if ICU won't guarantee cross-version compatibility, > because it destroys the argument that moving to ICU would offer us > collation behavior stability.
It would offer a significant upgrade over the current situation.
First, it offers stability inside the same version. Whereas glibc might change a collation in a minor upgrade, ICU won't do that. And the postgres binary is bound to a major version of ICU by the soname (which changes with every major release). So this would avoid the situation that a simple OS update could break collations.
Second, it offers a way to detect that something has changed. With glibc, you don't know anything unless you read the source diffs. With ICU, you can compare the collation version before and after and at least tell the user that they need to refresh indexes or whatever.
+1 on the importance of this last part.
We may not be able to handle it directly, but just being able to point out to the user that "this index is incorrect, you have to reindex" and then refuse to use the index until that has been done would be a *huge* improvement. And it would definitely help solve an existing real-world problem, which is what can happen when you restore a physical backup onto a different version of an operating system at least.
Sure, it would be even better if we could automatically *deal* with it. But failing in a loud and obvious way is a *lot* better than silently returning incorrect data...
