Re: SRF patch (was Re: [HACKERS] troubleshooting pointers)

Joe Conway <mail(at)joeconway(dot)com> writes:
> Tom Lane wrote:
>> In the parser. Ideally, fooid should not even be *visible* while we are
>> parsing the arguments to the sibling FROM node. Compare the handling of
>> variable resolution in JOIN/ON clauses --- the namespace gets
>> manipulated so that those clauses can't see vars from sibling FROM nodes.

> Attached patch takes care of this case. It also passes my previous test
> cases (see below). Applies cleanly to CVS tip and passes all regression
> tests. Please apply if there are no objections.

I've applied a simplified form of this patch --- it seemed you were
doing it the hard way. (Possibly I should have recommended
RangeSubselect as a model, not JOIN/ON. Like RangeSubselect,
RangeFunction doesn't need to allow *any* references to Vars of the
current query level.)

Further digging also revealed that query_tree_walker,
query_tree_mutator, and SS_finalize_plan had been missing out on their
responsibilities to process function-RTE expressions. With those things
fixed, it appears that outer-level Var references and sub-selects work
as expected in function-RTE expressions.

I am still concerned about whether ExecFunctionReScan works correctly;
if not, the problems would show up in join and subquery situations.
I think the parser and planner stages are in pretty good shape now,
though. (At least as far as the basic functionality goes. Having
a smarter materialization policy will take work in the planner.)

It's not too soon to start thinking about documentation and regression
tests for SRFs ...

regards, tom lane