Re: Pg_upgrade and collation

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-documentation <pgsql-docs(at)postgresql(dot)org>
Subject: Re: Pg_upgrade and collation
Date: 2016-06-28 21:58:58
Message-ID: CAH2-WznT0JzoRLBVGjUMO_vyFHHAEtHw9QhqFNn4SFAWMoc1Qw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs

On Fri, Jun 17, 2016 at 2:51 PM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message Bruce Momjian 2016-06-28 22:20:11 Re: Pg_upgrade and collation
Previous Message Bruce Momjian 2016-06-28 21:21:51 Re: Pg_upgrade and collation