Re: Better handling of parse errors

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Better handling of parse errors
Date: 2002-08-06 15:01:28
Message-ID: 19999.1028646088@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> writes:
> Attached is a small patch to scan.l for consideration. It hands
> yyerror() the position in the query string of the token which caused a
> parse error.

Isn't that the hard way to do it? Seems like you could just subtract
scanbuf from the error pointer, instead of adding overhead to the basic
lex loop.

Things that need to be decided (and documented somewhere):

Is the number an offset (counted from 0) or an index (counted from 1)?
Which end of the token does it point at? Can the message be phrased
so as to make it reasonably clear what the number is?

A related change I'd been meaning to make is to get it to say
parse error at end of input
when that's the case, rather than the rather useless
parse error at or near ""
that you get now. I'd still be inclined to just say "end of input"
in that case, and not bother with a character count.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2002-08-06 15:02:16 Re: FUNC_MAX_ARGS benchmarks
Previous Message Tom Lane 2002-08-06 14:40:32 Re: CVS sources doesn't compiles

Browse pgsql-patches by date

  From Date Subject
Next Message Jairo R.Oliveira - TERRA 2002-08-06 15:18:40 Problem: PostgreSQL/KYLIX
Previous Message Thomas Lockhart 2002-08-06 14:46:20 Re: pg_stat_reset round 3