Received: from localhost (unknown [200.46.204.183])
	by postgresql.org (Postfix) with ESMTP id AFA7E650424
	for <pgsql-hackers-postgresql.org@postgresql.org>;
	Mon, 28 Jul 2008 20:09:20 -0300 (ADT)
Received: from postgresql.org ([200.46.204.86])
	by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024)
	with ESMTP id 58169-07 for
	<pgsql-hackers-postgresql.org@postgresql.org>;
	Mon, 28 Jul 2008 20:09:09 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from alexis.jtlnet.com (alexis.jtlnet.com [69.36.9.81])
	by postgresql.org (Postfix) with ESMTP id B85F465038D
	for <pgsql-hackers@postgresql.org>;
	Mon, 28 Jul 2008 20:09:13 -0300 (ADT)
Received: from [192.168.10.103] (cpe-075-177-154-079.nc.res.rr.com
	[::ffff:75.177.154.79]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA)
	by alexis.jtlnet.com with esmtp; Mon, 28 Jul 2008 19:02:43 -0400
	id 0008BBEE.488E5013.00000A68
Message-ID: <488E5194.9060908@dunslane.net>
Date: Mon, 28 Jul 2008 19:09:08 -0400
From: Andrew Dunstan <andrew@dunslane.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.8.0.12) Gecko/20071019 Fedora/1.0.9-3.fc6 pango-text
	SeaMonkey/1.0.9
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Martijn van Oosterhout <kleptog@svana.org>,
	Andrew Gierth <andrew@tao11.riddles.org.uk>, pgsql-hackers@postgresql.org
Subject: Re: WITH RECUSIVE patches 0723
References: <20080725001513.GF16438@fetter.org>
	<20080725.092652.105178884.t-ishii@sraoss.co.jp>
	<87r69gs967.fsf@news-spur.riddles.org.uk>
	<20080728.162925.23020498.t-ishii@sraoss.co.jp>
	<19882.1217256991@sss.pgh.pa.us>
	<87myk1rg4z.fsf@news-spur.riddles.org.uk>
	<20080728222446.GC24856@svana.org> <203.1217286254@sss.pgh.pa.us>
In-Reply-To: <203.1217286254@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none
X-Spam-Level: 
X-Archive-Number: 200807/1337
X-Sequence-Number: 121597



Tom Lane wrote:
> My thought is that we could optimize away materialization in cases where
> we can tell it's not needed (no volatile functions and/or no multiple
> scans of the subquery).  But not being able to do it means we've
> implemented the feature incorrectly.
>
> 			
>   

I'm not sure how much work that would involve, but none of this means we 
can't have the feature for 8.4, right? Just that there is more work to do.

cheers

andrew