I have a nasty-looking problem case. Shortly described as follows:
INSERT INTO mytable (id, value) VALUES (4242, 'úabcdú');
SELECT id FROM mytable WHERE value ILIKE '%abc%';
In environment A, the row of the ID just inserted is returned
correctly, but in environment B no rows are found. Uh! (Sadly
environment B is the productive environment... :/)
Notice the UTF-8 chars in the inserted sting and the _lack_ of UTF-8
chars in the searched string.
Environment A: Win2000, psql 8.2.4, lc_* is C, all encondings (client,
server, DB) are UTF-8.
Environment B: Debian lenny/sid ^, kernel version 18.104.22.168, glibc
2.6.1-5, psql 8.2.5, lc_* is hu_HU, all encondings (client, server,
DB) are UTF-8.
^: I know :( but I'm not the sysadmin.
- The same query works if ILIKE is replaced with LIKE.
- In environment B, ILIKE '%bcdú%' also returns 0 rows, but ILIKE
'%bcd%' works well. Quite strange.
- I could not find the exact condition of the problem. A good lot of
queries work (provided the UTF-8 characters in the query exactly match
the DB value), but others like the above one do not.
- From my prev. googling, I've learnt that ILIKE does not handle
UTF-8 strings searched _for_, and I've already implemented a
workaround for that, but obviously I can't do much for this case, when
the operand is a simple ASCII string.
- From the first glance, this problem seems different from the ones
I've found during my searches (eg. links from
friends), but I'm not sure. If you think it's a new bug, please tell
it to me and I'll report it.
Well, any help is welcome, as our system is live and productive... :/
pgsql-bugs by date
|Next:||From: Pierre-yves Strub||Date: 2007-10-25 13:28:29|
|Subject: BUG #3696: FK integrity check bypassed using rules.|
|Previous:||From: Roger||Date: 2007-10-25 07:59:11|
|Subject: BUG #3695: Pgsql does not report non existing function|