> 2016-01-26 21:00 GMT+01:00 Daniel Verite <dan...@manitou-mail.org>: > >> Tatsuo Ishii wrote: >> >> > IMO, it's a bug or at least an inconsistency >> >> Personally I don't see this change being good for everything. >> >> Let's play devil's advocate: >> >> create table abc(U&"foo\2003" int); >> >> U+2003 is 'EM SPACE', in Unicode's General Punctuation block. >> >> With the current version, format('%I', attname) on this column is: >> "foo " >> >> With the patched version, it produces this: >> foo >> >> So the visual hint that there are more characters at the end is lost. >> > > I can agree, so current behave can be useful in some cases, but still it is > bug (inconsistency) between PostgreSQL parser and PostgreSQL escaping > functions. > > Currently, any multibyte char can be unescaped identifier (only apostrophes > are tested). We should to test white chars too.
Really? I thought we do that test. test=# create table t6("あいう えお" int); CREATE TABLE test=# \d t6 Table "public.t6" Column | Type | Modifiers -------------+---------+----------- あいう えお | integer | -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers