Re: [PATCHES] Better handling of parse errors - Mailing list pgsql-hackers

From Gavin Sherry
Subject Re: [PATCHES] Better handling of parse errors
Date
Msg-id Pine.LNX.4.21.0208190259240.13701-100000@linuxworld.com.au
Whole thread Raw
In response to Re: [PATCHES] Better handling of parse errors  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCHES] Better handling of parse errors
List pgsql-hackers
On Sun, 18 Aug 2002, Tom Lane wrote:

> Peter Eisentraut <peter_e@gmx.net> writes:
> > In strings.sql:
> 
> > -- illegal string continuation syntax
> > SELECT 'first line'
> > ' - next line' /* this comment is not allowed here */
> > ' - third line'
> >         AS "Illegal comment within continuation";
> > ERROR:  parser: parse error at or near "' - third line'" at character 89
> 
> > Character 89 is the end of the "third line" line, but the parse error is
> > at the beginning of that line.
> 
> This is fixed as of my later commit.
> 
> > In create_function_1.sql:
> 
> > CREATE FUNCTION test1 (int) RETURNS int LANGUAGE sql
> >     AS 'not even SQL';
> > ERROR:  parser: parse error at or near "not" at character 1
> 
> > Clearly confusing.
> 
> "Character 1" is correct as of the context that the parser is working
> in, namely the function body.  I don't think we can do much to change
> that, but perhaps we could make the message read like
> ERROR:  parser: parse error at or near "not" at character 1 of function body
> This would require giving the parser some sort of context-identifying
> string to tack onto the message, but that doesn't seem too hard.

Tom,

Reworking the code to taken into account token_start seems to work.
       elog(ERROR, "parser: %s at or near \"%s\" at character %i",           message,token_start ? token_start :
yytext,          token_start ? (unsigned int)(token_start - scanbuf + 1) :                         (unsigned
int)(yytext- scanbuf + 1));
 

I will submit a patch once I do some more testing to find other possible
situations where this plays up.

Gavin



pgsql-hackers by date:

Previous
From: Rod Taylor
Date:
Subject: Re: Remove implicit unique index creation on SERIAL
Next
From: Joe Conway
Date:
Subject: Re: Remove implicit unique index creation on SERIAL columns?