Re: SPI/backend equivalent of extended-query Describe(statement)? - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: SPI/backend equivalent of extended-query Describe(statement)?
Date
Msg-id 87vabayve8.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: SPI/backend equivalent of extended-query Describe(statement)?  (Chapman Flack <chap@anastigmatix.net>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: Redesigning the executor (async, JIT, memory efficiency)
Next
From: Andres Freund
Date:
Subject: Re: Redesigning the executor (async, JIT, memory efficiency)