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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: SPI/backend equivalent of extended-query Describe(statement)?
Дата
Msg-id 28641.1526320903@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: SPI/backend equivalent of extended-query Describe(statement)?  (Chapman Flack <chap@anastigmatix.net>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: some question about _bt_getbuf
Следующее
От: Garick Hamlin
Дата:
Сообщение: Re: Allow COPY's 'text' format to output a header