Re: BUG #1931: ILIKE and LIKE fails on Turkish locale - Mailing list pgsql-bugs

From Victor Snezhko
Subject Re: BUG #1931: ILIKE and LIKE fails on Turkish locale
Date
Msg-id uhcyzm4kv.fsf@indorsoft.ru
Whole thread Raw
In response to Re: BUG #1931: ILIKE and LIKE fails on Turkish locale  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #1931: ILIKE and LIKE fails on Turkish locale
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #1931: ILIKE and LIKE fails on Turkish locale
Next
From: Victor Snezhko
Date:
Subject: Re: BUG #1931: ILIKE and LIKE fails on Turkish locale