Re: [PATCH] Patch to fix a crash of psql

From: Tatsuo Ishii <ishii(at)postgresql(dot)org>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: peter_e(at)gmx(dot)net, laurenz(dot)albe(at)wien(dot)gv(dot)at, ishii(at)postgresql(dot)org, jianggq(at)cn(dot)fujitsu(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] Patch to fix a crash of psql
Date: 2012-11-30 16:29:06
Message-ID: 20121201.012906.918027897337860144.t-ishii@sraoss.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2012-11-30 16:34:55 Re: json accessors
Previous Message Hannu Krosing 2012-11-30 15:59:44 Re: json accessors