From: | Chapman Flack <chap(at)anastigmatix(dot)net> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: SPI/backend equivalent of extended-query Describe(statement)? |
Date: | 2018-05-26 02:09:25 |
Message-ID: | 5B08C1D5.1080609@anastigmatix.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 05/25/18 21:16, Andrew Gierth wrote:
>>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2018-05-26 02:10:52 | Re: Avoiding Tablespace path collision for primary and standby |
Previous Message | Andrew Gierth | 2018-05-26 01:16:04 | Re: SPI/backend equivalent of extended-query Describe(statement)? |