]> granicus.if.org Git - postgresql/commit
Fix SPI_cursor_open() and SPI_is_cursor_plan() to push the SPI stack before
authorTom Lane <tgl@sss.pgh.pa.us>
Tue, 12 Feb 2008 04:09:44 +0000 (04:09 +0000)
committerTom Lane <tgl@sss.pgh.pa.us>
Tue, 12 Feb 2008 04:09:44 +0000 (04:09 +0000)
commit745e6edaaeaccb92a2a5efe44b49c8bcc7d0ce01
treec5fe4bd66878be8422aeb74b58f77404c83411cb
parent953c2c9b71fff6c6e6952641077f29ef10b64398
Fix SPI_cursor_open() and SPI_is_cursor_plan() to push the SPI stack before
doing anything interesting, such as calling RevalidateCachedPlan().  The
necessity of this is demonstrated by an example from Willem Buitendyk:
during a replan, the planner might try to evaluate SPI-using functions,
and so we'd better be in a clean SPI context.

A small downside of this fix is that these two functions will now fail
outright if called when not inside a SPI-using procedure (ie, a
SPI_connect/SPI_finish pair).  The documentation never promised or suggested
that that would work, though; and they are normally used in concert with
other functions, mainly SPI_prepare, that always have failed in such a case.
So the odds of breaking something seem pretty low.

In passing, make SPI_is_cursor_plan's error handling convention clearer,
and fix documentation's erroneous claim that SPI_cursor_open would
return NULL on error.

Before 8.3 these functions could not invoke replanning, so there is probably
no need for back-patching.
doc/src/sgml/spi.sgml
src/backend/executor/spi.c