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" fortable "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@sss.pgh.pa.us>


> Peter Eisentraut <peter_e@gmx.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@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers