SRF patch (was Re: [HACKERS] Set Returning Functions (SRF) - request for patch review and comment)

Tom Lane wrote:
> Sure.  foo.foo is valid for a column foo in a table foo, so I don't
> see a problem with it for a function.

Fixed

>
> You could try doing the text substitution on the diff file and then
> re-applying the diff to fresh sources.  Might get a couple of merge
> failures, but should be a lot less painful than doing the edit directly
> on the full sources.
>

Great idea! Turned out to be a relatively painless 10 minute exercise.

> Up to you; probably should wait to see if Iter is still in your way
> after you do the other thing.  I think removing it and instead inserting
> returnsSet booleans in Oper and Func nodes would be a pretty
> straightforward exercise, but it'll mean touching even more stuff.
> Might be best to do that as a separate patch.

I'd like to wait on this -- I'm already drinking from a firehose ;-)


>
> Fair enough.  We should try to get the bulk of the patch applied soon
> so that you don't have code drift problems.  The rescan issues should
> not involve touching nearly as much code.

I also fixed the execute permissions, switched from ExecEvalFunc to
ExecEvalExpr, and fixed a bug that I found in _outRangeTblEntry (which
was preventing creation of a VIEW using a RangeFunction). If this could
be applied it would definitely help -- it's getting hard to keep it in
sync with cvs due to its size. The patch applies cleanly to cvs tip as
of a few minutes ago, and passes all regression tests.

Thanks,

Joe