Re: functions returning sets

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