@@ -330,3 +330,73 @@ error reporting.
330330
331331--Gene
332332
333+ From pgsql-patches-owner+M1499@postgresql.org Sat Aug 4 13:11:53 2001
334+ Return-path: <pgsql-patches-owner+M1499@postgresql.org>
335+ Received: from postgresql.org (webmail.postgresql.org [216.126.85.28])
336+ by candle.pha.pa.us (8.10.1/8.10.1) with ESMTP id f74HBrh11339
337+ for <pgman@candle.pha.pa.us>; Sat, 4 Aug 2001 13:11:53 -0400 (EDT)
338+ Received: from postgresql.org.org (webmail.postgresql.org [216.126.85.28])
339+ by postgresql.org (8.11.3/8.11.4) with SMTP id f74H89655183;
340+ Sat, 4 Aug 2001 13:08:09 -0400 (EDT)
341+ (envelope-from pgsql-patches-owner+M1499@postgresql.org)
342+ Received: from sss.pgh.pa.us ([192.204.191.242])
343+ by postgresql.org (8.11.3/8.11.4) with ESMTP id f74Gxb653074
344+ for <pgsql-patches@postgresql.org>; Sat, 4 Aug 2001 12:59:37 -0400 (EDT)
345+ (envelope-from tgl@sss.pgh.pa.us)
346+ Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
347+ by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id f74GtPC29183;
348+ Sat, 4 Aug 2001 12:55:25 -0400 (EDT)
349+ To: Dave Page <dpage@vale-housing.co.uk>
350+ cc: "'Fernando Nasser'" <fnasser@cygnus.com>,
351+ Bruce Momjian <pgman@candle.pha.pa.us>, Neil Padgett <npadgett@redhat.com>,
352+ pgsql-patches@postgresql.org
353+ Subject: Re: [PATCHES] Patch for Improved Syntax Error Reporting
354+ In-Reply-To: <8568FC767B4AD311AC33006097BCD3D61A2D70@woody.vale-housing.co.uk>
355+ References: <8568FC767B4AD311AC33006097BCD3D61A2D70@woody.vale-housing.co.uk>
356+ Comments: In-reply-to Dave Page <dpage@vale-housing.co.uk>
357+ message dated "Sat, 04 Aug 2001 12:37:23 +0100"
358+ Date: Sat, 04 Aug 2001 12:55:24 -0400
359+ Message-ID: <29180.996944124@sss.pgh.pa.us>
360+ From: Tom Lane <tgl@sss.pgh.pa.us>
361+ Precedence: bulk
362+ Sender: pgsql-patches-owner@postgresql.org
363+ Status: OR
364+
365+ Dave Page <dpage@vale-housing.co.uk> writes:
366+ > Oh, I quite agree. I'm not adverse to updating my code, I just want to avoid
367+ > users getting misleading messages until I come up with those updates.
368+
369+ Hmm ... if they were actively misleading then I'd share your concern.
370+
371+ I guess what you're thinking is that the error offset reported by the
372+ backend won't correspond directly to what the user typed, and if the
373+ user tries to use the offset to manually count off characters, he may
374+ arrive at the wrong place? Good point. I'm not sure whether a message
375+ like
376+
377+ ERROR: parser: parse error at or near 'frum';
378+ POSITION: 42
379+
380+ would be likely to encourage people to try that. Thoughts? (I do think
381+ this is a good argument for not embedding the position straight into the
382+ main error message though...)
383+
384+ One possible compromise is to combine the straight character-offset
385+ approach with a simplistic context display:
386+
387+ ERROR: parser: parse error at or near 'frum';
388+ POSITION: 42 ... oid,relname FRUM ...
389+
390+ The idea is to define the "POSITION" field as an integer offset possibly
391+ followed by whitespace and noise words. An updated client would grab
392+ the offset, ignore the rest of the field, and do the right thing. A
393+ not-updated client would display the entire message, and with any luck
394+ the user would read it correctly.
395+
396+ regards, tom lane
397+
398+ ---------------------------(end of broadcast)---------------------------
399+ TIP 5: Have you checked our extensive FAQ?
400+
401+ http://www.postgresql.org/users-lounge/docs/faq.html
402+