Marius Lorek <marius.lorek@xxxxxxxxx> writes: > If I have a table > create table my_table(id int primary key); > and a function > create function my_function() returns table(id int) stable as $$ select * > from my_table $$ language sql; > then Postgres knows that selecting from the function is really just > selecting from the table: > explain select * from my_function(); > QUERY PLAN > ------------------------------------------------------------ > Seq Scan on my_table (cost=0.00..35.50 rows=2550 width=4) > (1 row) What happened there is that the planner "inlined" the function while building a plan. > But if you prepare the same select statement and ask Postgres for a > description of it, then in the response the column "id" will have a > TableOID of 0 - even though we know, on some level, that it's going to be > selected straight from a table. The external properties of the prepared statement are determined long before that inlining happens; in particular they do not depend on the contents of the function. So the output column is merely perceived as coming from the declaration "returns table(id int)" of the function, which has no associated table. regards, tom lane
