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 5B08C1D5.1080609@anastigmatix.net
Whole thread Raw
In response to Re: SPI/backend equivalent of extended-query Describe(statement)?  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
List pgsql-hackers
On 05/25/18 21:16, Andrew Gierth wrote:
>>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>  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.

Now *that* sounds arguably bug-like ...could *it*, at least, be a candidate
for back-patching?

If it's currently not possible to use SPI_execute_plan/SPI_execute_snapshot
after SPI_prepare_params, then there can't be anything currently doing so,
that a patch could conceivably disrupt, can there?

-Chap


pgsql-hackers by date:

Previous
From: Andrew Gierth
Date:
Subject: Re: SPI/backend equivalent of extended-query Describe(statement)?
Next
From: Thomas Munro
Date:
Subject: Re: Avoiding Tablespace path collision for primary and standby