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
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 |