[HACKERS] Stopgap solution for ILIKE in multibyte encodings
I've gotten a little tired of reading reports that ILIKE doesn't work as expected in UTF8. The problem is that iwchareq() in like.c is several bricks shy of a load, as noticed e.g. here http://archives.postgresql.org/pgsql-bugs/2005-10/msg1.php I looked a little bit at making iwchareq less broken, but it seems like a mess because of the disconnect between pg_wchar and whatever the system towlower() function might be expecting. And in any case it can be expected that all this code will be thrown away someday, whenever we bite the bullet and do our own locale handling --- so I'm disinclined to spend a great deal of effort on it. I propose that for ILIKE in multibyte encodings, we just pass the strings through lower() and then use the normal LIKE code. This will be a bit slower than what we do now, but as a wise man once said, code can be arbitrarily fast if it needn't give the right answer. And we can't just ignore the bug for still another release cycle. Any objections? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Stopgap solution for ILIKE in multibyte encodings
Tom, On 9/4/06, Tom Lane [EMAIL PROTECTED] wrote: I propose that for ILIKE in multibyte encodings, we just pass the strings through lower() and then use the normal LIKE code. This will be a bit slower than what we do now, but as a wise man once said, code can be arbitrarily fast if it needn't give the right answer. And we can't just ignore the bug for still another release cycle. Perhaps it's a stupid question but what about the indexes? An index on lower(field) will be used by the new code or we wiil keep the current behaviour of ILIKE? Regards, -- Guillaume ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Stopgap solution for ILIKE in multibyte encodings
Guillaume Smet [EMAIL PROTECTED] writes: On 9/4/06, Tom Lane [EMAIL PROTECTED] wrote: I propose that for ILIKE in multibyte encodings, we just pass the strings through lower() and then use the normal LIKE code. Perhaps it's a stupid question but what about the indexes? An index on lower(field) will be used by the new code or we wiil keep the current behaviour of ILIKE? No, this is just an internal change in the function's implementation, it won't have any effect like that. If you want indexing you'd still need to write out lower(col) like whatever. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
