Thread: pgsql: Fix SPI_cursor_open() and SPI_is_cursor_plan() to push the SPI
pgsql: Fix SPI_cursor_open() and SPI_is_cursor_plan() to push the SPI
From
tgl@postgresql.org (Tom Lane)
Date:
Log Message: ----------- 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. Modified Files: -------------- pgsql/doc/src/sgml: spi.sgml (r1.59 -> r1.60) (http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/spi.sgml?r1=1.59&r2=1.60) pgsql/src/backend/executor: spi.c (r1.187 -> r1.188) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/spi.c?r1=1.187&r2=1.188)