Re: SPI/backend equivalent of extended-query Describe(statement)? - Mailing list pgsql-hackers

From Chapman Flack
Subject Re: SPI/backend equivalent of extended-query Describe(statement)?
Date
Msg-id d5ecbef6-88ee-85d8-7cc2-8c8741174f2d@anastigmatix.net
Whole thread Raw
In response to Re: SPI/backend equivalent of extended-query Describe(statement)?  (Chapman Flack <chap@anastigmatix.net>)
Responses Re: SPI/backend equivalent of extended-query Describe(statement)?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 05/24/2018 02:30 AM, Chapman Flack wrote:
> 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);

Am I on the right track here? Is what I'm looking to do something
that became possible in SPI in 9.0 and wasn't before, or did I overlook
a way it could have been done pre-9.0 ?

Thanks,
-Chap


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Performance regression with PostgreSQL 11 and partitioning
Next
From: Andres Freund
Date:
Subject: Re: found xmin from before relfrozenxid on pg_catalog.pg_authid