Re: Proposed patch for error locations - Mailing list pgsql-patches

From Tom Lane
Subject Re: Proposed patch for error locations
Date
Msg-id 7274.1142262691@sss.pgh.pa.us
Whole thread Raw
In response to Re: Proposed patch for error locations  (Michael Glaesemann <grzm@myrealbox.com>)
Responses Re: Proposed p.tch for error locations
Re: Proposed patch for error locations
List pgsql-patches
[ cross-posting to pgsql-interfaces in hopes of drawing more comments ]

Michael Glaesemann <grzm@myrealbox.com> writes:
> On Mar 13, 2006, at 2:37 , Tom Lane wrote:
>> http://archives.postgresql.org/pgsql-patches/2006-03/msg00153.php

> This looks really nice.

>> One thing I'm noticing already is that the addition of "at character N"
>> to a lot of these messages isn't an improvement.  In psql it's
>> certainly redundant with the error-cursor display.

> The pure character count is definitely difficult to use with larger
> queries. I think it could be more useful if it were
> line:char_of_line. Would others find this useful?

The change in behavior would actually be in libpq, because it's
PQerrorMessage that is doing the deed (assuming a reasonably modern
server and libpq).  What I was considering proposing was that we migrate
the error-cursor feature out of psql and into PQerrorMessage.  This
would mean that you'd get responses like

ERROR:  column "foo" does not exist
LINE 1: select foo from a;
               ^

from all libpq-using applications not just psql.  We could make this
conditional on the error verbosity --- in "terse" mode the "LINE N"
output wouldn't appear, and "at character N" still would.  Applications
should already be expecting multiline outputs from PQerrorMessage if
they're in non-terse mode, so this ought to be OK.  Comments?

            regards, tom lane

pgsql-patches by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: Proposed patch for error locations
Next
From: Alvaro Herrera
Date:
Subject: Re: Proposed p.tch for error locations