Re: Unicode string literals versus the world

Hi.

quick test for great patch. !

== SCRIPT ==
set CLIENT_ENCODING to 'UTF-8';
DROP TABLE ucheck CASCADE;
CREATE TABLE ucheck (key VARCHAR(10) PRIMARY KEY, data NCHAR(50));
set STANDARD_CONFORMING_STRINGS to on;
INSERT INTO ucheck VALUES('ucheck1',u&'\68ee\9dd7\5916');
SELECT * FROM ucheck;
set CLIENT_ENCODING to 'SHIFTJIS2004';
SELECT * FROM ucheck;
set STANDARD_CONFORMING_STRINGS to off;
INSERT INTO ucheck VALUES('ucheck2',u&'\68ee\9dd7\5916');

=== As for psql ===
This should notice the console of Japanese windows-XP about code can't to display.

C:\work>psql
psql (8.4beta1)
"help" でヘルプを表示します.

HIROSHI=# set CLIENT_ENCODING to 'UTF-8';
SET
HIROSHI=# DROP TABLE ucheck CASCADE;
DROP TABLE
HIROSHI=# CREATE TABLE ucheck (key VARCHAR(10) PRIMARY KEY, data NCHAR(50));
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "ucheck_pkey" for
table "ucheck"
CREATE TABLE
HIROSHI=# set STANDARD_CONFORMING_STRINGS to on;
SET
HIROSHI=# INSERT INTO ucheck VALUES('ucheck',u&'\68ee\9dd7\5916');
INSERT 0 1
HIROSHI=# SELECT * FROM ucheck;
key | data
--------+-------------------------------------------------------
ucheck | 譽ョ鮃怜、・
(1 行)

HIROSHI=# set CLIENT_ENCODING to 'SHIFTJIS2004';
SET
HIROSHI=# SELECT * FROM ucheck;
key | data
--------+-------------------------------------------------------
ucheck | 森・外
(1 行)

HIROSHI=# set STANDARD_CONFORMING_STRINGS to off;
SET
HIROSHI=# INSERT INTO ucheck VALUES('ucheck2',u&'\68ee\9dd7\5916');
ERROR: unsafe use of string constant with Unicode escapes
DETAIL: String constants with Unicode escapes cannot be used when standard_conf
orming_strings is off.

=== As for pgAdminIII ===
pgadmin is shown very well.!!:-)
http://winpg.jp/~saito/pg_work/ucheck/jisx0213.png

P.S)
This test obtains the same result by MimerDB.

Regards,
Hiroshi Saito

----- Original Message -----
From: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>

> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> On Tuesday 14 April 2009 21:34:51 Peter Eisentraut wrote:
>>> I think we can handle that and the cases Tom presents by erroring out when
>>> the U& syntax is used with stdstr off.
>
>> Proposed patch for that attached.
>
> I have not been able to think of any security hole in that proposal,
> so this patch seems acceptable to me. I wonder though whether any
> corresponding change is needed in psql's lexer, and if so how should
> it react exactly to the rejection case.
>
> regards, tom lane
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers