Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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

pgsql-hackers by date

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

pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group