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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, Tatsuo Ishii *EXTERN* <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 15:36:06
Message-ID: 12977.1354289766@sss.pgh.pa.us
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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-11-30 15:42:21 Re: Re: missing LockBuffer(buffer, BUFFER_LOCK_SHARE) in trigger.c GetTupleForTrigger?
Previous Message Andrew Dunstan 2012-11-30 15:29:47 Re: json accessors