Andrew Gierth <and...@tao11.riddles.org.uk> writes:
> "Tom" == Tom Lane <t...@sss.pgh.pa.us> writes:
> 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 :-)
The worrisome thing is the possibility that some other extension tries
to add to (or otherwise change) the post_parse_analyze_hook list while
you have it in a temporary state. I can't think of a really likely
scenario for that, because I don't think parse analysis would ever cause
loading of a shared library that wasn't loaded already ... but just to
state that assumption is to expose how non-future-proof it is.
Really our hook mechanism only supports adding hooks, not removing them.
> 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.
I'm not following why that's such a problem? The whole point of
SPI_prepare_params and friends is that the actual number and types
of the parameters is hidden behind the parse hooks and ParamListInfo
--- and, indeed, could change from one execution to the next.
SPI_execute_plan only makes sense with a predetermined, fixed
parameter list.
regards, tom lane
