On 05/14/18 11:29, Tom Lane wrote:
> 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?
Huh ... let me go read those again. Sure sound promising. Right there on
the SPI contents page, too. I wonder if I was so suggestible that I read
that comment and it blinded me to them, or I saw them and assumed they
didn't do what you'd expect, because of the comment....
The story gets better. Those two functions were added to SPI in March '04,
in 65a0db1, submitted by Thomas Hallgren himself.
Before being pushed in core, they had existed in PL/Java since January '04,
d917e46, eight days after he wrote that comment. They disappeared in
October '05 when he dropped support for PG < 8. And he had reworked
ExecutionPlan.c to make use of them (that is, after the Java code has
already bound Java values to the parameters, the native code does consult
SPI_getargtypeid while converting those to PG datums).
But he never removed that comment about getParameterMetaData, and I think
it's still correct (except for the blame-SPI part), because it looks like
he never got around to updating /that/ code to pass along the
SPI_getargtypeid info mapped to Java types so the Java caller can ask
what types to supply.
That looks like something I could fix....
Where should I look to learn more about the capabilities of the type
inference done in planning? Not everything-there-is-to-know, but basics
like, can some simple query constructs reliably cause an intended type to
be reported? I assume if the query is "SELECT ?" then the reported argtype
will be unknown. If changed to, say, "SELECT ?::foo", will that report
a type of foo for the parameter, or continue to report the parameter
as untyped because it isn't needed to type the cast expression?
(In XQuery they made up distinct constructs "cast as" and "treat as"
to leave no such conundrum.)
-Chap
