Alex Pilosov <alex@pilosoft.com> writes:
> Well, a lot of things (planner for ex) need to know relid of the relation
> being returned.
Only if there *is* a relid. Check out the handling of
sub-SELECT-in-FROM for a more reasonable model.
It's quite likely that you'll need another variant of RangeTblEntry to
represent a function call. I've been thinking that RangeTblEntry should
have an explicit type code (plain rel, subselect, inheritance tree top,
and join were the variants I was thinking about at the time; add
"function returning tupleset" to that) and then there could be a union
for the fields that apply to only some of the variants.
> Variables (for example) have to be bound to relid and attno. If a function
> returns setof int4, what should be variables' varno be?
I'd say that such a function's output will probably be implicitly
converted to single-column tuples in order to store it in the portal
mechanism. So the varno is 1. Even if the execution-time mechanism
doesn't need to do that, the parser has to consider it that way to allow
a column name to be assigned to the result. Example:
select x+1 from funcreturningsetofint4();
What can I write for "x" to make this work? There isn't anything.
I have to assign a column alias to make it legal:
select x+1 from funcreturningsetofint4() as f(x);
Here, x must clearly be regarded as the first (and only) column of the
rangetable entry for "f".
> Okay. So the logic should support 'select * from foo' where foo is portal,
> right?
Yeah, that was what I had up my sleeve ... then
select * from mycursor limit 1;
would be more or less equivalent to
fetch 1 from mycursor;
regards, tom lane
