Add to syntax error reporting.

This commit is contained in:
Bruce Momjian 2001-09-06 16:30:46 +00:00
parent 343e38a938
commit 4f952aaa5b
1 changed files with 70 additions and 0 deletions

View File

@ -330,3 +330,73 @@ error reporting.
--Gene
From pgsql-patches-owner+M1499@postgresql.org Sat Aug 4 13:11:53 2001
Return-path: <pgsql-patches-owner+M1499@postgresql.org>
Received: from postgresql.org (webmail.postgresql.org [216.126.85.28])
by candle.pha.pa.us (8.10.1/8.10.1) with ESMTP id f74HBrh11339
for <pgman@candle.pha.pa.us>; Sat, 4 Aug 2001 13:11:53 -0400 (EDT)
Received: from postgresql.org.org (webmail.postgresql.org [216.126.85.28])
by postgresql.org (8.11.3/8.11.4) with SMTP id f74H89655183;
Sat, 4 Aug 2001 13:08:09 -0400 (EDT)
(envelope-from pgsql-patches-owner+M1499@postgresql.org)
Received: from sss.pgh.pa.us ([192.204.191.242])
by postgresql.org (8.11.3/8.11.4) with ESMTP id f74Gxb653074
for <pgsql-patches@postgresql.org>; Sat, 4 Aug 2001 12:59:37 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id f74GtPC29183;
Sat, 4 Aug 2001 12:55:25 -0400 (EDT)
To: Dave Page <dpage@vale-housing.co.uk>
cc: "'Fernando Nasser'" <fnasser@cygnus.com>,
Bruce Momjian <pgman@candle.pha.pa.us>, Neil Padgett <npadgett@redhat.com>,
pgsql-patches@postgresql.org
Subject: Re: [PATCHES] Patch for Improved Syntax Error Reporting
In-Reply-To: <8568FC767B4AD311AC33006097BCD3D61A2D70@woody.vale-housing.co.uk>
References: <8568FC767B4AD311AC33006097BCD3D61A2D70@woody.vale-housing.co.uk>
Comments: In-reply-to Dave Page <dpage@vale-housing.co.uk>
message dated "Sat, 04 Aug 2001 12:37:23 +0100"
Date: Sat, 04 Aug 2001 12:55:24 -0400
Message-ID: <29180.996944124@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-patches-owner@postgresql.org
Status: OR
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...)
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.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html