On tis, 2011-08-02 at 16:47 -0400, Tom Lane wrote:
> The most straightforward way to reimplement things within spi.c would
> be to redefine SPI_prepare as just doing the parse-and-rewrite steps,
> with planning always postponed to SPI_execute. In the case where you
> just prepare and then execute a SPIPlan, this would come out the same
> or better, since we'd still just do one planning cycle, but the
> planner could be given the actual parameter values to use. However,
> if you SPI_prepare, SPI_saveplan, and then SPI_execute many times, you
> might come out behind. This is of course the same tradeoff we are
> going to impose at the SQL level anyway, but I wonder whether there
> needs to be a control knob available to C code to retain the old
> plan-once-and-always-use-that-plan approach.
How about a new function like SPI_parse that has the new semantics?
Note that the SPI functions are more or less directly exposed in PL/Perl
and PL/Python, and there are a number of existing idioms there that make
use of prepared plans. Changing the semantics of those functions might
upset a lot of code.