Re: SPI/backend equivalent of extended-query Describe(statement)? - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: SPI/backend equivalent of extended-query Describe(statement)?
Date
Msg-id 874liv1auh.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: SPI/backend equivalent of extended-query Describe(statement)?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: SPI/backend equivalent of extended-query Describe(statement)?  (Chapman Flack <chap@anastigmatix.net>)
Re: SPI/backend equivalent of extended-query Describe(statement)?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:

 >>> /*
 >>> * GAH. To do parameter type checking properly, we have to install our
 >>> * own global post-parse hook transiently.
 >>> */

 >> Gah, indeed. Thanks for the heads up. I would never have guessed it'd
 >> be that fiddly.

 Tom> Yikes.  That seems pretty unsafe :-(

I put in a recursion check out of paranoia, but even after considerable
thought wasn't able to figure out any scenario that would actually break
it. If it's actually unsafe I'd really like to know about it :-)

 Tom> Obviously, I missed a bet by not folding check_variable_parameters
 Tom> into the pstate hook mechanism. It's a bit late to do anything
 Tom> about that for v11, but I'd favor trying to improve the situation
 Tom> in v12.

Yeah. Another issue I ran into is that if you use SPI_prepare_params,
then you have to use SPI_execute_plan_with_paramlist, it's not possible
to use SPI_execute_plan (or SPI_execute_snapshot) instead because
plan->nargs was set to 0 by the prepare and never filled in with the
actual parameter count.

-- 
Andrew (irc:RhodiumToad)


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: SPI/backend equivalent of extended-query Describe(statement)?
Next
From: Chapman Flack
Date:
Subject: Re: SPI/backend equivalent of extended-query Describe(statement)?