RE: Patch for Improved Syntax Error Reporting

> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: 04 August 2001 17:55
> 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:
> > 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.
>
> Hmm ... if they were actively misleading then I'd share your concern.
>
> I guess what you're thinking is that the error offset
> reported by the backend won't correspond directly to what the
> user typed, and if the user tries to use the offset to
> manually count off characters, he may arrive at the wrong
> place?  Good point.  I'm not sure whether a message like
>
>     ERROR:  parser: parse error at or near 'frum';
>     POSITION: 42
>
> would be likely to encourage people to try that.  Thoughts?
> (I do think this is a good argument for not embedding the
> position straight into the main error message though...)

Yes, that is precisely what I'm thinking.

> One possible compromise is to combine the straight
> character-offset approach with a simplistic context display:
>
>     ERROR:  parser: parse error at or near 'frum';
>     POSITION: 42  ... oid,relname FRUM ...
>
> The idea is to define the "POSITION" field as an integer
> offset possibly followed by whitespace and noise words.  An
> updated client would grab the offset, ignore the rest of the
> field, and do the right thing.  A not-updated client would
> display the entire message, and with any luck the user would
> read it correctly.

That sounds good, though I'll bet that M$ ADO will chop the message at the
whitespace anyway! :-( Of course, that's my problem...

Regards, Dave.