Excerpts from Dimitri Fontaine's message of dom oct 17 16:30:47 -0300 2010:
> The bulk of it is now short enough to be inlined in the mail, and if you
> have more comments I guess they'll be directed at this portion of the
> patch, so let's make it easy:
>
> /*
> * We abuse some internal knowledge from spi.h here. As we don't know
> * which queries are going to get executed, we don't know what to expect
> * as an OK return code from SPI_execute(). We assume that
> * SPI_OK_CONNECT, SPI_OK_FINISH and SPI_OK_FETCH are quite improbable,
> * though, and the errors are negatives. So a valid return code is
> * considered to be SPI_OK_UTILITY or anything from there.
> */
> SPI_connect();
> if (SPI_execute(query_string, false, 0) < SPI_OK_UTILITY)
> ereport(ERROR,
> (errcode(ERRCODE_DATA_EXCEPTION),
> errmsg("File '%s' contains invalid query", filename)));
> SPI_finish();
SPI_OK_FETCH is indeed improbable -- it's not used anywhere in the SPI
routines, and hasn't been for ages. SPI_OK_CONNECT and SPI_OK_FINNISH
are only issued by SPI_connect and SPI_finish, so presumably they can't
be returned by a script.
The error message wording needs some work; maybe
errmsg("file \"%s\" could not be executed", filename)
SPI_execute sets the query as errcontext, which is good; but apparently
there is no error position, which is bad. I'm not sure how feasible is
to fix this. (Not this patch's responsibility anyway.)
I happened to notice that there are several pieces of code that are
calling SPI_connect and SPI_finish without checking the return value,
notably the FTS code and xml.c.
--
Álvaro Herrera <alvhe...@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
