Re: Status report on writeable CTEs

2010/7/21 David Fetter <david(at)fetter(dot)org>:
> On Sat, Jul 17, 2010 at 01:15:22AM +0900, Hitoshi Harada wrote:
>> 2010/7/17 Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>:
>> > On 7/16/10 6:15 PM +0300, Hitoshi Harada wrote:
>> >> 1. Use MaterialNode instead of adding DtScanNode. Since MaterialNode
>> >> is exsiting one that work with single tuplestore, it might be sane to
>> >> modify this so that it accepts tuplestore from Query instead of its
>> >> child node.
>> >
>> > I thought about this, but I don't necessarily like the idea of overloading
>> > executor nodes.
>>
>> Neither do I have good shape for this solution. Maybe it's not good
>> idea. But my concern is adding DtScanNode, which looks similar to
>> MaterialNode. Of course each purpose is different, but quite big part
>> will overlap each other, I think.
>
> Any ideas as to how to factor this out?  Handiest ideas would be in
> the form of a patch ;)

Yeah, that would be handiest, but I think I must wait for his first
compilable patch to modify to try the idea. Current version looks
quite messy and can't build.

>> >> 2. Use temp table instead of tuplestore list. Since we agreed we need
>> >> to execute each plan one by one starting and shutting down executor,
>> >> it now looks very simple strategy.
>> >
>> > I didn't look at this because I thought using a "tuplestore receiver" in the
>> > portal logic was simple enough.  Any thoughts on how this would work?
>>
>> It's just deconstructing queries like:
>>
>> WITH t AS (INSERT INTO x ... RETURING *)
>> SELECT * FROM t;
>>
>> to
>>
>> CREATE TEMP TABLE t AS INSERT INTO x ... RETURING *;
>> SELECT * FROM t;
>>
>> While the second statement is not implemented yet, it will be so simpler.
>
> So CTAS would get expanded into CTA[row-returning query] ?
> Interesting.  How much work would that part be?

FWIW, this is getting interesting to me these days, and I think this
can be separated from wCTE

As hackers say, the first to try should be Marko's first design that
use the list of tuplestore and DTScanNode. So if he has solid image to
reach there, we can wait for him to complete his first compilable
version. Then let's take it back and forth. Is it possible?

And I concern we might not have concrete consensus about list of
features in document form. Does it accept Recursive query? What if x
refers to y that refers to x cyclicly? An external design sometimes
fix the internal design, and it helps people to review the
implementation. If I missed something please point me to the link.

Regards,

--
Hitoshi Harada