Re: SPI/backend equivalent of extended-query Describe(statement)?

>>>>> "Chapman" == Chapman Flack <chap@anastigmatix.net> writes:

 >> Really our hook mechanism only supports adding hooks, not removing
 >> them.

 Chapman> I suppose the pllua_spi_prepare_checkparam_hook could be
 Chapman> linked in once and for all, and turned on and off just where
 Chapman> the code now hooks and unhooks it, and just forward to the
 Chapman> next hook when it's off.

Yeah, or have it detect whether the ParseState it's being called for is
ours by some other means.

 >> 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.

So while looking at the hook issue, I found another can of worms.

What a protocol-level Parse does is to call parse-analysis via
parse_analyze_varparams, which calls parse_variable_parameters _without_
making it a parser setup hook (either there or in CompleteCachedPlan).

This has the effect of casting the parameter types in stone on the first
parse, as the client expects; a subsequent revalidate of the statement
will use pg_analyze_and_rewrite, which takes a fixed parameter list.

However if you call parse_variable_parameters from a hook passed to
SPI_prepare_params, then you're asking for it to be called again on
revalidations, which means that the parameters might change (even if
just changing types, I think you'd need a more complex set of hooks than
parse_variable_parameters uses to change the number of parameters too).

So what I'm thinking now is that the way to go, if one wants to imitate
the client-side protocol behavior closely, would be to have a setup hook
that calls parse_variable_parameters the first time, and then
parse_fixed_parameters on subsequent calls for revalidation.

-- 
Andrew (irc:RhodiumToad)