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
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 |