Re: Collations and Replication; Next Steps

From: Tatsuo Ishii <ishii(at)postgresql(dot)org>
To: stark(at)mit(dot)edu
Cc: ishii(at)postgresql(dot)org, mkelly(at)tripadvisor(dot)com, robertmhaas(at)gmail(dot)com, kleptog(at)svana(dot)org, pg(at)heroku(dot)com, peter_e(at)gmx(dot)net, pgsql-hackers(at)postgresql(dot)org, mspilich(at)tripadvisor(dot)com
Subject: Re: Collations and Replication; Next Steps
Date: 2014-09-17 23:46:21
Message-ID: 20140918.084621.1532340783089281990.t-ishii@sraoss.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Wed, Sep 17, 2014 at 3:47 PM, Tatsuo Ishii <ishii(at)postgresql(dot)org> wrote:
>> I don't think we cannot achieve that because even MySQL accomplishes:-)
>
> We've always considered it an advantage that we're consistent with the
> collations in the rest of the system. Generally speaking the fact that
> Postgres integrates with the system rather than be a separate system
> unto itself.
>
> Consider bug reports like "I've configured my system to use
> fr_FR.UTF-8 and "sort" produces output in this order why is Postgres
> producing output in a different order? Or extension authors using
> strcoll and being surprised that the module gets inconsistent data
> from the database.

I doubt it. glibc takes liberty to change the collation data release
by release, but people don't seem to complain it. Then why would
people complain the collation difference between PostgreSQL and glibc
if there's any?

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2014-09-18 00:11:33 Yet another abort-early plan disaster on 9.3
Previous Message Tatsuo Ishii 2014-09-17 23:41:36 Re: Collations and Replication; Next Steps