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

Поиск
Список
Период
Сортировка
От Andrew Gierth
Тема Re: SPI/backend equivalent of extended-query Describe(statement)?
Дата
Msg-id 874liv1auh.fsf@news-spur.riddles.org.uk
обсуждение исходный текст
Ответ на Re: SPI/backend equivalent of extended-query Describe(statement)?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: SPI/backend equivalent of extended-query Describe(statement)?
Re: SPI/backend equivalent of extended-query Describe(statement)?
Список pgsql-hackers
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:

 >>> /*
 >>> * GAH. To do parameter type checking properly, we have to install our
 >>> * own global post-parse hook transiently.
 >>> */

 >> Gah, indeed. Thanks for the heads up. I would never have guessed it'd
 >> be that fiddly.

 Tom> Yikes.  That seems pretty unsafe :-(

I put in a recursion check out of paranoia, but even after considerable
thought wasn't able to figure out any scenario that would actually break
it. If it's actually unsafe I'd really like to know about it :-)

 Tom> Obviously, I missed a bet by not folding check_variable_parameters
 Tom> into the pstate hook mechanism. It's a bit late to do anything
 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.

-- 
Andrew (irc:RhodiumToad)


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: SPI/backend equivalent of extended-query Describe(statement)?
Следующее
От: Chapman Flack
Дата:
Сообщение: Re: SPI/backend equivalent of extended-query Describe(statement)?