Re: BUG #1931: ILIKE and LIKE fails on Turkish locale
От | Bruce Momjian |
---|---|
Тема | Re: BUG #1931: ILIKE and LIKE fails on Turkish locale |
Дата | |
Msg-id | 200606142100.k5EL0D820171@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #1931: ILIKE and LIKE fails on Turkish locale (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #1931: ILIKE and LIKE fails on Turkish locale
Re: BUG #1931: ILIKE and LIKE fails on Turkish locale |
Список | pgsql-bugs |
Did we make any progress on this? If so, I can't find it. --------------------------------------------------------------------------- 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 EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-bugs по дате отправления: