|From:||Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||Chapman Flack <chap(at)anastigmatix(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org|
|Subject:||Re: SPI/backend equivalent of extended-query Describe(statement)?|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
|Next Message||Chapman Flack||2018-05-26 02:09:25||Re: SPI/backend equivalent of extended-query Describe(statement)?|
|Previous Message||Tom Lane||2018-05-26 00:55:48||Re: SPI/backend equivalent of extended-query Describe(statement)?|