Re: ICU integration

From: Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>
To: craig(at)2ndquadrant(dot)com
Cc: peter(dot)eisentraut(at)2ndquadrant(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, ddoole(at)salesforce(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: ICU integration
Date: 2016-09-09 00:51:54
Message-ID: 20160909.095154.1130083428657813367.t-ishii@sraoss.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 9 September 2016 at 00:19, Peter Eisentraut
> <peter(dot)eisentraut(at)2ndquadrant(dot)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.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2016-09-09 01:19:54 Re: Install extensions using update scripts (was Re: Remove superuser() checks from pgstattuple)
Previous Message Andres Freund 2016-09-09 00:43:41 Re: _mdfd_getseg can be expensive