MIME-Version: 1.0
In-Reply-To: <20160617215154.GA140481@alvherre.pgsql>
References: <20160617154311.GB19359@momjian.us>
 <20160617215154.GA140481@alvherre.pgsql>
From: Peter Geoghegan <pg@bowt.ie>
Date: Tue, 28 Jun 2016 14:58:58 -0700
Message-ID: 
 <CAH2-WznT0JzoRLBVGjUMO_vyFHHAEtHw9QhqFNn4SFAWMoc1Qw@mail.gmail.com>
Subject: Re: Pg_upgrade and collation
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Bruce Momjian <bruce@momjian.us>,
 PostgreSQL-documentation <pgsql-docs@postgresql.org>
Content-Type: text/plain; charset=UTF-8
Precedence: bulk
Sender: pgsql-docs-owner@postgresql.org

On Fri, Jun 17, 2016 at 2:51 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> I think this is way too thin to be helpful:
>
>> --- 61,68 ----
>>     checking for compatible compile-time settings, including 32/64-bit
>>     binaries.  It is important that
>>     any external modules are also binary compatible, though this cannot
>> !   be checked by <application>pg_upgrade</>.  Compatible collation
>> !   library versions must also be used.
>>    </para>

Unfortunately, the reality is that as things stand, there is no way to
test compatibility on all platforms. Glibc does have a notion of
collation versioning, though [1].

I have long advocated adopting ICU as our defacto standard "collation
provider", primarily so that we can directly control collations and
collation versioning. I think that doing this would solve many
problems. Besides, even SQLite has optional ICU support. PostgreSQL is
the only major database system that I'm aware of that relies on
operating system collations exclusively.

I've avoided committing to work on it because I'm concerned that it
would not be well received.

[1] https://www.gnu.org/software/autoconf/manual/autoconf-2.63/html_node/Special-Shell-Variables.html
-- 
Peter Geoghegan


-- 
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs