On 15/01/2014 13:29, Amit Langote wrote: > On Wed, Jan 15, 2014 at 9:02 PM, Ivan Voras <ivo...@freebsd.org> wrote: >> On 15/01/2014 12:36, Amit Langote wrote:
>>> * In some locales strcoll() can claim that >>> nonidentical strings are >>> * equal. Believing that would be bad news for a >>> number of reasons, >>> * so we follow Perl's lead and sort "equal" strings >>> according to >>> * strcmp(). >>> */ >>> if (result == 0) >>> result = strcmp(a1p, a2p); >> >> That seems odd and inefficient. Why would it be necessary? I would think >> indexing (and other collation-sensitive operations) don't care what the >> actual collation result is for arbitrary blobs of strings, as long as >> they are stable? >> > > This is the behavior since quite some time introduced by this commit > > http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=656beff59033ccc5261a615802e1a85da68e8fad Ok, the commit comment is: "Adjust string comparison so that only bitwise-equal strings are considered equal: if strcoll claims two strings are equal, check it with strcmp, and sort according to strcmp if not identical. This fixes inconsistent behavior under glibc's hu_HU locale, and probably under some other locales as well. Also, take advantage of the now-well-defined behavior to speed up texteq, textne, bpchareq, bpcharne: they may as well just do a bitwise comparison and not bother with strcoll at all." ... so it's just another workaround for OS specific locale issues - to me it looks like just another reason to use ICU.
signature.asc
Description: OpenPGP digital signature
