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

Поиск
Список
Период
Сортировка
От Andrew Gierth
Тема Re: SPI/backend equivalent of extended-query Describe(statement)?
Дата
Msg-id 87vabayve8.fsf@news-spur.riddles.org.uk
обсуждение исходный текст
Ответ на Re: SPI/backend equivalent of extended-query Describe(statement)?  (Chapman Flack <chap@anastigmatix.net>)
Список pgsql-hackers
>>>>> "Chapman" == Chapman Flack <chap@anastigmatix.net> writes:

 >> So what I'm thinking now is that the way to go, if one wants to
 >> imitate the client-side protocol behavior closely, would be to have
 >> a setup hook that calls parse_variable_parameters the first time,
 >> and then parse_fixed_parameters on subsequent calls for
 >> revalidation.

 Chapman> What circumstances would call for revalidation, and what would
 Chapman> it be able to accomplish, under that design?

Any change that could invalidate the cached plan, such as altering any
of the tables referenced by it.

But thinking about it more (and actually trying it out in pllua-ng),
it's not as bad as I thought because parse_variable_parameters on
revalidation (at least the way I do it) will still be using the same
parameter types array as before, which will have the types of all
actually used parameters already filled in, and so those won't be
changed.

I think in the absence of a columnref hook, that means that the number
and type of parameters found when using parse_variable_parameters can't
change after the first time, so there's probably no need to get too
fancy in the hook.

-- 
Andrew (irc:RhodiumToad)


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Redesigning the executor (async, JIT, memory efficiency)
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Redesigning the executor (async, JIT, memory efficiency)