Re: Collations and Replication; Next Steps

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Collations and Replication; Next Steps
Дата
Msg-id CA+TgmobbrqUD6FiDdqpdT35X83e3pPEZdzko7uZp-08MFJdm5w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Collations and Replication; Next Steps  (Matthew Kelly <mkelly@tripadvisor.com>)
Ответы Re: Collations and Replication; Next Steps  (Peter Geoghegan <pg@heroku.com>)
Список 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 по дате отправления:

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: Re: Collations and Replication; Next Steps
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Final Patch for GROUPING SETS