On 9 September 2016 at 08:51, Tatsuo Ishii <is...@sraoss.co.jp> wrote: >> On 9 September 2016 at 00:19, Peter Eisentraut >> <peter.eisentr...@2ndquadrant.com> 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. >> >> It also lets *users* and PostgreSQL-specific distributors bundle ICU >> and get stable collations. We can't exactly bundle glibc. > > I would like to know the fate of community RPMs because if PostgreSQL > does not include ICU source, the effort of integrating ICU is totally > up to packagers.
CC'ing Devrim. Personally I would be pretty reluctant to package libicu when it's already in RH/Fedora. If it were bundled in Pg's source tree and a private copy was built/installed by the build system so it was part of the main postgresql-server package that'd be different. I can't really imagine that being acceptable for upstream development though. RH and Debian would instantly rip it out and replace it with their packaged ICU anyway. Pity ICU doesn't offer versioned collations within a single install. Though I can understand why they don't. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
