Re: WITH RECUSIVE patches 0723 - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: WITH RECUSIVE patches 0723
Date
Msg-id 873altsyay.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: WITH RECUSIVE patches 0723  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: WITH RECUSIVE patches 0723  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>> I think it needs this change in addition; without it, incorrect>> results are returned when you reference a
recursiveview from>> within the recursive query, due to the RecursionScan nodes>> becoming linked to the wrong
tuplestores.
Tom> That whole business of using the EState to pass tuplestores backTom> and forth looks fundamentally broken to me
anyway;there's justTom> no way it'll be certain to link the right nodes together inTom> complicated cases with multiple
recursions.

Mutual recursion is not allowed; as far as I can determine, every
remaining case is such that any RecursiveScan node should be
referencing the nearest parent Recursion node, which is what the patch
(with the above fix) does.

If you have a counterexample I'd be interested to see it; I've spent a
significant amount of time looking at this code, and I can't find one.
Tom> The nodes should be carrying IDs (such as the name of the WITHTom> item) which they use to search a lookaside
list.

create view v0 as with recursive t(id) as (select ...);
with recursive t(id) as (select ... from v0 ...) select ...;

That gives you two WITH items with the same name. You would need
additional qualification of some sort.

-- 
Andrew (irc:RhodiumToad)


pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: Do we really want to migrate plproxy and citext into PG core distribution?
Next
From: Dave Cramer
Date:
Subject: Re: Protocol 3, Execute, maxrows to return, impact?