On 05/14/18 11:29, Tom Lane wrote: > Chapman Flack <c...@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