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

From: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
To: Chapman Flack <chap(at)anastigmatix(dot)net>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: SPI/backend equivalent of extended-query Describe(statement)?
Date: 2018-05-26 21:27:29
Message-ID: 87vabayve8.fsf@news-spur.riddles.org.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>>>> "Chapman" == Chapman Flack <chap(at)anastigmatix(dot)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)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2018-05-26 22:45:59 Re: Redesigning the executor (async, JIT, memory efficiency)
Previous Message Robert Haas 2018-05-26 21:08:51 Re: Redesigning the executor (async, JIT, memory efficiency)