Re: Collations and Replication; Next Steps - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Collations and Replication; Next Steps
Date
Msg-id CA+TgmobbrqUD6FiDdqpdT35X83e3pPEZdzko7uZp-08MFJdm5w@mail.gmail.com
Whole thread Raw
In response to Re: Collations and Replication; Next Steps  (Matthew Kelly <mkelly@tripadvisor.com>)
Responses Re: Collations and Replication; Next Steps
List pgsql-hackers
On Wed, Sep 17, 2014 at 10:06 AM, Matthew Kelly <mkelly@tripadvisor.com> wrote:
> Let me double check that assertion before we go too far with it.
>
> Most of the problems I've seen are across 5 and 6 boundaries.  I thought I had case where it was within a minor
releasebut I can't find it right now.  I'm going to dig. 
>
> That being said the sort order changes whether you statically or dynamically link (demonstrated on 4+ machines
runningdifferent linux flavors), so at the point I have no reason to trust the stability of the sort across any build.
Ilegitimately question whether strcoll is buggy.  Ex. I have cases where for three strings a, b and c:  a > b, but  (a
||c) < (b || c).  That's right postfixing doesn't hold.  It actually calls into question the index scan optimization
thatoccurs when you do LIKE 'test%' even on a single machine, but I don't want to bite that off at the moment. 
>
> My mentality has switched to 'don't trust any change until shown otherwise', so that may have bled into my last
email.

Of course, there's also the question of whether ICU would have similar
issues.  You're assuming that they *don't* whack the collation order
around in minor releases, or at least that they do so to some lesser
degree than glibc, but is that actually true?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: Collations and Replication; Next Steps
Next
From: Josh Berkus
Date:
Subject: Re: Final Patch for GROUPING SETS