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

From: Chapman Flack <chap(at)anastigmatix(dot)net>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: SPI/backend equivalent of extended-query Describe(statement)?
Date: 2018-05-14 05:12:47
Message-ID: 5AF91ACF.30706@anastigmatix.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

I ask because I've stumbled on this 14½ year old (earliest days!) comment
in PL/Java's PreparedStatement.getParameterMetaData():

* Due to the design of the <code>SPI_prepare</code>, it is currently
* impossible to obtain the correct parameter meta data before all the
* parameters have been set, hence a ParameterMetaData obtained prior to
* setting the paramteres will have all parameters set to the default type
* {(at)link Types#VARCHAR}.
* Once the parameters have been set, a fair attempt is made to generate this
* object based on the supplied values.

Apparently it seemed difficult at the time to implement a
getParameterMetaData that could tell you the thing you want to know
(what parameter types are expected so you can supply them), but less
difficult to implement something that can't tell you until you've
supplied them and then tells you what you supplied. Problem solved,
in a way that's entertaining but a little short on utility. :)

I'll admit that in my own perusal of the SPI docs, I don't see an
obvious advertised way to get that information about a prepared
statement, either. But the information has to exist somewhere, and
a remote client is able to ask for it, so where should I be looking
for the means of retrieving it in the backend?

-Chap

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2018-05-14 05:29:18 Re: Incorrect comment in get_partition_dispatch_recurse
Previous Message David Rowley 2018-05-14 05:00:34 Re: Needless additional partition check in INSERT?