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