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

From Tom Lane
Subject Re: SPI/backend equivalent of extended-query Describe(statement)?
Date
Msg-id 20198.1526311786@sss.pgh.pa.us
Whole thread Raw
In response to SPI/backend equivalent of extended-query Describe(statement)?  (Chapman Flack <chap@anastigmatix.net>)
Responses Re: SPI/backend equivalent of extended-query Describe(statement)?  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: SPI/backend equivalent of extended-query Describe(statement)?  (Chapman Flack <chap@anastigmatix.net>)
List pgsql-hackers
Chapman Flack <chap@anastigmatix.net> writes:
> The longer version of $subject is: how would one go about, in the
> backend using SPI (or SPI and maybe other server APIs as needed),
> obtaining the same inferred parameter information that a front-end
> client can get with the Describe (statement variant) extended-query
> message?

If you're talking about the plan's input parameters, don't SPI_getargcount
and SPI_getargtypeid do what you need?

If you want to know about the output column types, SPI doesn't seem to
have a nice way of getting that in advance of execution, but you could
emulate what Describe does:

* Use SPI_plan_get_plan_sources to get a list of CachedPlanSources
(up to you to decide what to do if there's more or less than one CPS)

* For each/selected CPS, look at the resultDesc and/or targetlist
similarly to SendRowDescriptionMessage.

            regards, tom lane


pgsql-hackers by date:

Previous
From: 自己
Date:
Subject: some question about _bt_getbuf
Next
From: Alvaro Herrera
Date:
Subject: Re: \d doesn't show partitioned table foreign keys