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 22:25:11
Message-ID: 8749.1029709511@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:
> 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 into
parse 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message redmonde 2002-08-18 22:25:48 assigning to NULL?
Previous Message Tom Lane 2002-08-18 22:08:15 Re: Open 7.3 items

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2002-08-18 22:32:46 Re: bytea operator bugs (was Re: [GENERAL] BYTEA, indexes and "like")
Previous Message Joe Conway 2002-08-18 21:54:09 Re: BYTEA, indexes and "like"