Add to syntax error reporting.

Author: bmomjian

doc/TODO.detail/yacc

@@ -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
+