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