On Thu, Sep 8, 2016 at 12:19:39PM -0400, Peter Eisentraut wrote: > 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.
Uh, how do we know that ICU doesn't change collations in minor versions? Couldn't we get into a case where the OS changes the ICU version or collations more frequently than glibc does? Seems that would be a negative. I don't see how having our binary bound to a ICU major version gives us any benefit. It seems we are still hostage to the OS version. > 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. Yes, that is a clear win. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
