> Peter Eisentraut <pete...@gmx.net> writes: >> On 11/30/12 3:26 AM, Albe Laurenz wrote: >>> If there is no possibility for false positives, I'd say >>> that the "possible" should go. Maybe it should even be >>> an error and no warning then. > >> Yes, encoding mismatches are generally an error. > >> I think the message should be more precise. Nobody will know what an >> "encoding conflict" is. The error condition is "last multibyte >> character ran over end of file" or something like that, which should be >> clearer. > > TBH I think that a message here is unnecessary; it's sufficient to > ensure psql doesn't crash. The backend will produce a better message > than this anyway once the data gets there, and that way we don't have to > invent a new error recovery path inside psql. As-is, the patch just > creates the question of what to do after issuing the error.
Problem is, backend does not always detect errors. For my example backend caches an error: postgres=# \i ~/a psql:/home/t-ishii/a:1: warning: possible conflict between client encoding SJIS and input file encoding ERROR: invalid byte sequence for encoding "SJIS": 0x88 psql:/home/t-ishii/a:1: ERROR: invalid byte sequence for encoding "SJIS": 0x88 However for Jiang Guiqing's example, backend silently ignores error: postgres=# \i ~/sql CREATE DATABASE You are now connected to database "mydb" as user "t-ishii". CREATE SCHEMA psql:/home/t-ishii/sql:7: warning: possible conflict between client encoding SJIS and input file encoding CREATE TABLE IMO it is a benefit for users to detect such errors earlier. -- 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 (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
