From: | Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Better handling of parse errors |
Date: | 2002-08-06 12:27:59 |
Message-ID: | Pine.LNX.4.21.0208062227370.17111-100000@linuxworld.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
On Tue, 6 Aug 2002, Bruce Momjian wrote:
>
> Can we see some sample output?
template1=# select * frum pg_class;
ERROR: parser: parse error at or near "frum" at character 10
template1=# select relname from pg_class a excepr select relname from
pg_class limit a;
ERROR: parser: parse error at or near "excepr" at character 32
template1=# create table a (desc int);
ERROR: parser: parse error at or near "desc" at character 17
Gavin
>
> ---------------------------------------------------------------------------
>
> Gavin Sherry wrote:
> > Hi all,
> >
> > 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. It is not even close to an implementation of error handling
> > a-la SQL99 but it certainly makes debugging complicated queries easier.
> >
> > I've done some testing and it appears to hit the offending token pretty
> > accurately.
> >
> > Can anyone find a way to break this? If not, I'd love to see it in 7.3.
> >
> > Gavin
>
> Content-Description:
>
> [ Attachment, skipping... ]
>
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 6: Have you searched our list archives?
> >
> > http://archives.postgresql.org
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Gavin Sherry | 2002-08-06 12:39:18 | Re: Better handling of parse errors |
Previous Message | Bruce Momjian | 2002-08-06 12:23:54 | Re: Better handling of parse errors |
From | Date | Subject | |
---|---|---|---|
Next Message | Gavin Sherry | 2002-08-06 12:39:18 | Re: Better handling of parse errors |
Previous Message | Bruce Momjian | 2002-08-06 12:23:54 | Re: Better handling of parse errors |