Re: SPI/backend equivalent of extended-query Describe(statement)?

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

In response to

Browse pgsql-hackers by date

  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)?