From: Bruce Momjian Date: Thu, 6 Sep 2001 16:30:46 +0000 (+0000) Subject: Add to syntax error reporting. X-Git-Tag: REL7_2_BETA1~524 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=4f952aaa5b5e26ceb30aeeed91bf58d9e347d2c5;p=postgresql Add to syntax error reporting. --- diff --git a/doc/TODO.detail/yacc b/doc/TODO.detail/yacc index 9aba8cae96..8e7fa8986c 100644 --- a/doc/TODO.detail/yacc +++ b/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: +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 ; 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 ; 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 +cc: "'Fernando Nasser'" , + Bruce Momjian , Neil Padgett , + 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 + 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 +Precedence: bulk +Sender: pgsql-patches-owner@postgresql.org +Status: OR + +Dave Page 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 +