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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: SRF patch (was Re: [HACKERS] troubleshooting pointers)
Date: 2002-05-18 19:02:17
Message-ID: 23078.1021748537@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Neil Conway 2002-05-18 19:18:53 Re: SASL, compression?
Previous Message Nigel J. Andrews 2002-05-18 18:52:27 *new* libpgtcl - backend version information patch

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2002-05-18 20:11:59 Re: [INTERFACES] libpgtcl - backend version information patch
Previous Message Nigel J. Andrews 2002-05-18 18:52:27 *new* libpgtcl - backend version information patch