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" <t...@sss.pgh.pa.us>
Peter Eisentraut <pete...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
