Re: functions returning sets

Alex Pilosov <alex(at)pilosoft(dot)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