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