> Peter Eisentraut <peter_e@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
