aboutsummaryrefslogtreecommitdiff
path: root/src/tutorial/complex.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2008-02-12 04:09:44 +0000
committerTom Lane <tgl@sss.pgh.pa.us>2008-02-12 04:09:44 +0000
commit745e6edaaeaccb92a2a5efe44b49c8bcc7d0ce01 (patch)
treec5fe4bd66878be8422aeb74b58f77404c83411cb /src/tutorial/complex.c
parent953c2c9b71fff6c6e6952641077f29ef10b64398 (diff)
downloadpostgresql-745e6edaaeaccb92a2a5efe44b49c8bcc7d0ce01.tar.gz
postgresql-745e6edaaeaccb92a2a5efe44b49c8bcc7d0ce01.zip
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.
Diffstat (limited to 'src/tutorial/complex.c')
0 files changed, 0 insertions, 0 deletions