RE: Patch for Improved Syntax Error Reporting

> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: 02 August 2001 23:12
> To: Dave Page
> Cc: 'Fernando Nasser'; Bruce Momjian; Neil Padgett;
> pgsql-patches@postgresql.org
> Subject: Re: [PATCHES] Patch for Improved Syntax Error Reporting
>
>
> Dave Page <dpage@vale-housing.co.uk> writes:
> > However, pgAdmin does pretty much just the reformatting you've
> > suggested, including stripping of comments (well that's in the new
> > codebase anyway),
> > so:
>
> > -- Simple Query
> > SELECT
> >   oid,
> >   relname
> > FRUM
> >   pg_class
>
> > becomes:
>
> > SELECT oid, relname FRUM pg_class
>
> > Giving the error
>
> > ERROR:  parser: parse error at or near 'frum':
> > SELECT oid, relname FRUM pg_class
> >                     ^
>
> > Which would still be useful of course.
>
> Yes, but on that size of query you hardly need a syntax error
> pointer anyway.  Consider what happens when the query is
> several thousand characters long and the error message wraps
> across several dozen lines (as does the spaces-and-caret
> pointer line).  Now you really *need* that error pointer, but
> good luck making any use of what's displayed :-(

Yes, point taken.

> Another reason why the simplistic approach is not all that
> useful is that the reformatting might itself be or mask the
> problem.  Suppose I fat-finger my query so that I have an
> accidentally unterminated comment, or the code recognizes a
> comment where I didn't intend one.  The error message
> produced by the backend will omit the parts of the query that
> the client code thought were comments, which is likely to
> make it harder not easier for me to figure out what I did
> wrong --- not least because it eliminates cues I might
> otherwise use to figure out which part of a large query
> string is being complained about.

Again, point taken.

> Basically, upgrading syntax-error behavior to something
> useful will take some cooperation from the client side as
> well as the backend.  IMHO we shouldn't dumb down our
> ambitions to be merely what can be implemented without any
> client cooperation.

Oh, I quite agree. I'm not adverse to updating my code, I just want to avoid
users getting misleading messages until I come up with those updates.

Regards, Dave.