Re: Pg_upgrade and collation

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Pg_upgrade and collation
Дата
Msg-id CAH2-WznT0JzoRLBVGjUMO_vyFHHAEtHw9QhqFNn4SFAWMoc1Qw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Pg_upgrade and collation  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: Pg_upgrade and collation  (Bruce Momjian <bruce@momjian.us>)
Re: Pg_upgrade and collation  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список pgsql-docs
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


В списке pgsql-docs по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Pg_upgrade and collation
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Pg_upgrade and collation