Re: BUG #1931: ILIKE and LIKE fails on Turkish locale

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #1931: ILIKE and LIKE fails on Turkish locale
Дата
Msg-id 9028.1128184301@sss.pgh.pa.us
обсуждение исходный текст
Ответ на BUG #1931: ILIKE and LIKE fails on Turkish locale  ("Devrim GUNDUZ" <devrim@gunduz.org>)
Ответы Re: BUG #1931: ILIKE and LIKE fails on Turkish locale  (Devrim GUNDUZ <devrim@gunduz.org>)
Re: BUG #1931: ILIKE and LIKE fails on Turkish locale  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: BUG #1931: ILIKE and LIKE fails on Turkish locale  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: "Devrim GUNDUZ"
Дата:
Сообщение: BUG #1931: ILIKE and LIKE fails on Turkish locale
Следующее
От: Devrim GUNDUZ
Дата:
Сообщение: Re: BUG #1931: ILIKE and LIKE fails on Turkish locale