Re: SRF patch (was Re: [HACKERS] troubleshooting pointers) - Mailing list pgsql-patches

From Tom Lane
Subject Re: SRF patch (was Re: [HACKERS] troubleshooting pointers)
Date
Msg-id 23078.1021748537@sss.pgh.pa.us
Whole thread Raw
In response to Re: SRF patch (was Re: [HACKERS] troubleshooting pointers)  (Joe Conway <mail@joeconway.com>)
List pgsql-patches
Joe Conway <mail@joeconway.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

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: patch for examples
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] [INTERFACES] libpgtcl - backend version information patch