Re: Patch for Improved Syntax Error Reporting

Bruce Momjian wrote:
>
> > > My 2c:
> > >
> > > Why not do tom's suggestion for the POSITION: n thing, and modify psql to
> > > strip out that header, and output the relevant part of the sql with a caret
> > > highlighting the error position.
> > >
> > > This will make it so that writers of the guis and format errors how they
> > > like, and users of the most popular text interface (psql) get human-readable
> > > results...
> > >
> > > ie. best of both worlds...
> >
> > OK, I withdraw my objection.
> >
> > Also, I like the idea of adding Hints and Function/line numbers to the
> > output too. The offset of the error would work into that system.
>
> I guess the thing that bothered me is that 90% of our interfaces are
> just going to throw the carret under the error line and this patch
> requires us to modify all the client interfaces to do that, just to
> allow 10% to customize their display.
>
> Now, I know we are going to allow elog() to generate filename, line
> number, and function name as optional output information. We could have
> a SET paramter like:
>
> SET SYSOUTPUT TO "message, function, offset"
>
> and this displays:
>
> ERROR: lkjasdf
> FUNCTION: lkjasdf
> OFFSET: 2343
>
> and we could have an option for HIGHLIGHT:
>
> HIGHLIGHT: FROM tab1, tab2
> HIGHLIGHT: ^^^^
>
> We could control this via GUC or via the client startup code, and
> clients could grab whatever they want to know about an error.

I think it seems that we all have a general idea of where we want to go
with this. How about the following as a plan to get this ready for 7.2:

1. Leave elog() alone.
2. For syntax error reporting, and syntax error reporting alone, output
the error message in the new, multi-line format from the backend.
3. Add functionality to psql for parsing the multi-line format error
messages. (Probably this will form a reusable function library that
other utilities can use.)
4. Modify psql to use this new functionality, but only for processing
parse errors -- all other messages will be handled as is.

Thoughts?

Neil

--
Neil Padgett
Red Hat Canada Ltd. E-Mail: npadgett(at)redhat(dot)com
2323 Yonge Street, Suite #300,
Toronto, ON M4P 2C9