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

Поиск
Список
Период
Сортировка
От Chapman Flack
Тема Re: SPI/backend equivalent of extended-query Describe(statement)?
Дата
Msg-id 5B08C1D5.1080609@anastigmatix.net
обсуждение исходный текст
Ответ на Re: SPI/backend equivalent of extended-query Describe(statement)?  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Список 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 по дате отправления:

Предыдущее
От: Andrew Gierth
Дата:
Сообщение: Re: SPI/backend equivalent of extended-query Describe(statement)?
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: Avoiding Tablespace path collision for primary and standby