>>>>> "Chapman" == Chapman Flack <c...@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)
