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