Re: BUG #1931: ILIKE and LIKE fails on Turkish locale - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #1931: ILIKE and LIKE fails on Turkish locale
Date
Msg-id 9028.1128184301@sss.pgh.pa.us
Whole thread Raw
In response to BUG #1931: ILIKE and LIKE fails on Turkish locale  ("Devrim GUNDUZ" <devrim@gunduz.org>)
Responses Re: BUG #1931: ILIKE and LIKE fails on Turkish locale
Re: BUG #1931: ILIKE and LIKE fails on Turkish locale
Re: BUG #1931: ILIKE and LIKE fails on Turkish locale
List pgsql-bugs
"Devrim GUNDUZ" <devrim@gunduz.org> writes:
> http://sourceware.org/bugzilla/long_list.cgi?buglist=1354
> So it is PostgreSQL's bug or Glibc's?

Just offhand, iwchareq() seems several bricks shy of a load:

    /*
     * if one of them is an ASCII while the other is not, then they must
     * be different characters
     */
    else if ((unsigned char) *p1 < CHARMAX || (unsigned char) *p2 < CHARMAX)
        return (0);

This test is wrong per Jakub's observation.  Also, the code right below
that is using tolower() not towlower() on wide characters, which seems
pretty wrong.  For that matter, towlower would be wrong too :-( because
there is no certainty that libc's idea of wide characters is the same as
pg_mb2wchar_with_len's.

So yeah, ILIKE looks just about completely broken for multibyte encodings.
Maybe it would be best to pass both strings through lower() and then
do a normal LIKE comparison?

The regexp code doesn't look better, btw, just differently broken ...

            regards, tom lane

pgsql-bugs by date:

Previous
From: "Devrim GUNDUZ"
Date:
Subject: BUG #1931: ILIKE and LIKE fails on Turkish locale
Next
From: Devrim GUNDUZ
Date:
Subject: Re: BUG #1931: ILIKE and LIKE fails on Turkish locale