On 05/14/18 13:46, Chapman Flack wrote:
> On 05/14/18 11:29, Tom Lane wrote:
>> Chapman Flack <c...@anastigmatix.net> writes:
>>> The longer version of $subject is: how would one go about, in the
>>> backend using SPI (or SPI and maybe other server APIs as needed),
>>> obtaining the same inferred parameter information that a front-end
>>> client can get with the Describe (statement variant) extended-query
>>> message?
>>
>> If you're talking about the plan's input parameters, don't SPI_getargcount
>> and SPI_getargtypeid do what you need?
>
> Huh ... let me go read those again. Sure sound promising. Right there on
I'm not sure I'm out of the woods yet. The extended-query-protocol
documentation clearly advertises that you can send param oids of zero,
or send fewer of them than the actual number of params, and get the
unspecified ones inferred. And exec_parse_message() pointedly calls
parse_analyze_varparams(), with a comment saying "Note that the originally
specified parameter set is not required to be complete, so we have to use
parse_analyze_varparams()."
The SPI_prepare docs don't contain any similar advertisement of what to do
if you want parameter types inferred ... and the code doesn't appear to
call parse_analyze_varparams, at least never before PG 9.0.
In 9.0, there's SPI_prepare_params, which seems promising; it accepts
an arbitrary ParserSetupHook "to control the parsing of external parameter
references." But its documentation doesn't suggest what to use as the
ParserSetupHook to say "please just do the same stuff you would do if
I were a client sending a Parse message with unspecified parameter types!"
Perhaps I just need something like
struct varparinfo { Oid *paramTypes, int numParams } vpi = {palloc(0), 0};
static void inferringSetupHook(struct ParseState *pstate, void *arg)
{
struct varparinfo *vpi = (struct varparinfo *)arg;
parse_variable_parameters(pstate, &vpi->paramTypes, &vpi->numParams);
}
SPI_prepare_params("SELECT $1", inferringSetupHook, &vpi, 0);
?
So, does this mean this really couldn't have been done in SPI earlier
than 9.0, and that old pre-9.0 comment from Thomas was completely accurate?
Were there no other PLs needing to do that before? Is SQL/JRT the only
spec for a PL that presupposes a prepare-describe-bind-execute model
where 'describe' tells you the inferred parameter types? I would have
assumed that was more common.
-Chap
