Re: ICU integration
От | Bruce Momjian |
---|---|
Тема | Re: ICU integration |
Дата | |
Msg-id | 20160922031651.GA15646@momjian.us обсуждение исходный текст |
Ответ на | Re: ICU integration (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Список | pgsql-hackers |
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 <bruce@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 +
В списке pgsql-hackers по дате отправления: