Thread: Stopgap solution for ILIKE in multibyte encodings

Stopgap solution for ILIKE in multibyte encodings

From
Tom Lane
Date:
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/msg00001.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


Re: Stopgap solution for ILIKE in multibyte encodings

From
"Guillaume Smet"
Date:
Tom,

On 9/4/06, Tom Lane <tgl@sss.pgh.pa.us> 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


Re: Stopgap solution for ILIKE in multibyte encodings

From
Tom Lane
Date:
"Guillaume Smet" <guillaume.smet@gmail.com> writes:
> On 9/4/06, Tom Lane <tgl@sss.pgh.pa.us> 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