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

From Bruce Momjian
Subject Re: BUG #1931: ILIKE and LIKE fails on Turkish locale
Date
Msg-id 200510132033.j9DKXnj06406@candle.pha.pa.us
Whole thread Raw
In response to Re: BUG #1931: ILIKE and LIKE fails on Turkish locale  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
This has been saved for the 8.2 release:

    http://momjian.postgresql.org/cgi-bin/pgpatches_hold

---------------------------------------------------------------------------

Tom Lane wrote:
> "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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
>                http://archives.postgresql.org
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #1956: Plpgsql top-level DECLARE does not share scope
Next
From: Bruce Momjian
Date:
Subject: Re: BUG #1962: ECPG and VARCHAR