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 28641.1526320903@sss.pgh.pa.us
Whole thread Raw
In response to Re: SPI/backend equivalent of extended-query Describe(statement)?  (Chapman Flack <chap@anastigmatix.net>)
List pgsql-hackers
Chapman Flack <chap@anastigmatix.net> writes:
> Where should I look to learn more about the capabilities of the type
> inference done in planning?

It's not terribly well documented outside the source code, I fear.

> 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?

That will result in reporting the parameter as having type foo, cf
variable_coerce_param_hook().  Experimenting with this sort of stuff
isn't hard, eg in psql:

regression=# prepare p1 as select $1;
PREPARE
regression=# prepare p2 as select $1::bigint;
PREPARE
regression=# select name, parameter_types from pg_prepared_statements ;
 name | parameter_types 
------+-----------------
 p1   | {text}
 p2   | {bigint}
(2 rows)

(Before v10, p1 would have failed PREPARE for lack of a determinate
type for the parameter, which I think corresponds to sending back
UNKNOWN in the wire-protocol-prepare case.)

            regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: some question about _bt_getbuf
Next
From: Garick Hamlin
Date:
Subject: Re: Allow COPY's 'text' format to output a header