Re: Writeable CTEs and empty relations - Mailing list pgsql-hackers

From Marko Tiikkaja
Subject Re: Writeable CTEs and empty relations
Date
Msg-id 4B734B9F.3010400@cs.helsinki.fi
Whole thread Raw
In response to Re: Writeable CTEs and empty relations  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Writeable CTEs and empty relations
List pgsql-hackers
On 2010-02-11 01:58 +0200, Robert Haas wrote:
> On Wed, Feb 10, 2010 at 6:25 PM, Marko Tiikkaja
> <marko.tiikkaja@cs.helsinki.fi> wrote:
>> On 2010-02-11 00:50 +0200, Marko Tiikkaja wrote:
>> Ok, what about the following:
>>  - after planning the original query, standard_planner() goes through
>>    the list of top-level CTEs and assigns a running number for each of
>>    the DML WITHs, in the order they will be executed and returns a
>>    list of PlannedStmts.  all necessary statements wi have a flag
>>    signaling that the result should be stored in a tuplestore.
>>  - the portal keeps the list of tuplestores around and passes that
>>    list to every query through PlannedStmt.  it keeps on executing
>>    the statements until it finds a PlannedStmt that doesn't want its
>>    results stored anywhere and then frees the list of tuplestores
> 
> Wouldn't you'd want to stop when you ran out of PlannedStmts, not when
> you hit one that didn't need its results stored?  What happens if
> there's an unreferenced CTE in the middle of the list?

Right, of course.

>> Does this sound reasonable?  And more importantly, am I going to be
>> wasting my time implementing this?  The 15th isn't that far away..
> 
> I have to admit I've been starting to have a feeling over the last
> couple of days that this patch isn't going to make it for 9.0...  but
> obviously I'm in no position to guarantee anything one way or the
> other.  Please do keep us up to date on your plans, though.

Unfortunately, so have I.  I'll take a shot at implementing this, but if
I come across any problems, I have to give up.


Regards,
Marko Tiikkaja


pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: Odd cruft in .psql_history in HEAD
Next
From: Bruce Momjian
Date:
Subject: Re: psql tab completion for DO blocks