Re: [PATCHES] Better handling of parse errors

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PATCHES] Better handling of parse errors
Дата
Msg-id 24196.1029689587@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [PATCHES] Better handling of parse errors  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: [PATCHES] Better handling of parse errors
Re: [PATCHES] Better handling of parse errors
Список pgsql-hackers
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.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Remove implicit unique index creation on SERIAL columns?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Open 7.3 items