Re: BUG #1931: ILIKE and LIKE fails on Turkish locale
От | Victor Snezhko |
---|---|
Тема | Re: BUG #1931: ILIKE and LIKE fails on Turkish locale |
Дата | |
Msg-id | uhcyzm4kv.fsf@indorsoft.ru обсуждение исходный текст |
Ответ на | 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
|
Список | pgsql-bugs |
Tom Lane <tgl@sss.pgh.pa.us> writes: >> ... I think we need convert_ident to >> use a plpgsql_isspace() that accepts these and only these as spaces. >> Any high-bit-set byte is part of an identifier according to scan.l's >> rules, and convert_ident must have the same behavior regardless of local= e. > >> There may be related risks in and around the other flex scanners >> ... will look. > > I've committed a fix along these lines. ecpg had the identical bug, but > I couldn't find any other places where we seemed to be assuming that > <ctype.h> macros would match the behavior of our flex scanners. Thank you, your commit has fixed this issue.=20 The issue with empty table names (when they are multibyte) remains. The following queries work as expected: (I use table named as "=D4" - Unicode 0442, and column named as "=CB" - Unicode id 043A)=20 CREATE TABLE =D4 ( =CB int NOT NULL, PRIMARY KEY (=CB) ); INSERT INTO =D4 (=CB) VALUES (1); SELECT * FROM =D4; However, in system catalogs (SELECT * FROM pg_tables WHERE schemaname=3D'public') there appears to be empty strings instead=20=20 of table names. This is on patched 8.1.4 (with ILIKE and ctype.h fixes), I'm upgrading to HEAD now to see if anything improved. --=20 WBR, Victor V. Snezhko E-mail: snezhko@indorsoft.ru
В списке pgsql-bugs по дате отправления: