On Dec 20, 2009, at 12:03 AM, Tom Lane wrote:
> This looks like it's most likely redundant with the stuff I added
> recently for the plpgsql parser rewrite. Please see if you can use that
> instead.
The parser param hooks will definitely work. As for getting the result TupleDesc prior to execution, I can include
spi_priv.hand look at the CPS list directly. Something more crayola would be preferable, but I don't think
"SPI_prepare_statement"is that something; although, it did make for a fine stopgap. (Well, "fine", saving that my
proposedSPI_prepare_statement appeared to be broken wrt plan revalidation and bound parameters.. ew)
So, after looking into the parser hooks, CachedPlanSource, and SPI more, I ended up taking a slightly different route.
Iexpect it to work with a couple prior versions of PG as well, so there is some added value over a new SPI function or
exclusivelyusing param hooks. And, now, thinking of compatibility with past versions of PG, I'll find a different route
for"SPI_execute_statements" as well.
Thanks.
