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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
