On Fri, 29 Jun 2001, Tom Lane wrote:
> 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.
Thank you!
>
> 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.
I don't think I've got the balls to do this one, cuz it'd need to be
modified in many places. I'll just add another field there for my use and
let someone clean it up later. :)
> > 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".
more fun for grammar, but I'll try.
> > 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;
Neat possibilities.
