Re: [PATCHES] Better handling of parse errors - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCHES] Better handling of parse errors
Date
Msg-id 8749.1029709511@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCHES] Better handling of parse errors  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> "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

> That would be better.

After a quick look through the sources, it seems we could fairly easily
do this: callers of pg_parse_and_rewrite() and some related routines
could pass a string like "SQL function body", which would get plugged
into the parse-error message.  Two issues though:

* Is this okay from an internationalization point of view?  We can
gettext() the "SQL function body" string but I don't know if there
are serious problems with pasting that intoparse error at or near "%s" at character %d of %s
On the other hand I'm not comfortable with having the far-end caller
supply that whole string, either, since most of it is the lexer's
responsibility.

* The natural thing to say in _SPI_execute's call is "SPI query",
but this will probably not go over big with plpgsql users, who will
see that and probably have no idea what SPI is.  But I'm very
loathe to change the SPI API so that plpgsql can pass down the
context string --- that'll break existing user functions that use
SPI.  Do we want to uglify the SPI API to the extent of having
parallel calls that just add a context string parameter?  Is there
a better way?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Open 7.3 items
Next
From: redmonde@purdue.edu
Date:
Subject: assigning to NULL?