Re: [PATCHES] Better handling of parse errors

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCHES] Better handling of parse errors
Date: 2002-08-18 16:53:07
Message-ID: 24196.1029689587@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Peter Eisentraut <peter_e(at)gmx(dot)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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-08-18 16:55:41 Re: Open 7.3 items
Previous Message Tom Lane 2002-08-18 16:46:47 Re: Remove implicit unique index creation on SERIAL columns?

Browse pgsql-patches by date

  From Date Subject
Next Message Gavin Sherry 2002-08-18 17:05:40 Re: [PATCHES] Better handling of parse errors
Previous Message Alvar Freude 2002-08-18 12:47:18 BYTEA, indexes and "like"