X-Original-To: pgsql-hackers-postgresql.org@postgresql.org
Received: from localhost (wm.hub.org [200.46.204.128])
	by postgresql.org (Postfix) with ESMTP id 04C569FA5CD
	for <pgsql-hackers-postgresql.org@postgresql.org>;
	Thu, 20 Jul 2006 02:18:45 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024)
	with ESMTP id 95859-03 for
	<pgsql-hackers-postgresql.org@postgresql.org>;
	Thu, 20 Jul 2006 05:18:41 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-
Received: from joeconway.com (wsip-68-15-9-201.sd.sd.cox.net [68.15.9.201])
	by postgresql.org (Postfix) with ESMTP id BD49E9FA502
	for <pgsql-hackers@postgresql.org>;
	Thu, 20 Jul 2006 02:18:40 -0300 (ADT)
Received: from [192.168.4.40] (account jconway [192.168.4.40] verified)
	by joeconway.com (CommuniGate Pro SMTP 4.1.8)
	with ESMTP-TLS id 4056849; Wed, 19 Jul 2006 22:18:39 -0700
Message-ID: <44BF122F.1080200@joeconway.com>
Date: Wed, 19 Jul 2006 22:18:39 -0700
From: Joe Conway <mail@joeconway.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Christopher Kings-Lynne <chris.kings-lynne@calorieking.com>,
	"Hackers (PostgreSQL)" <pgsql-hackers@postgresql.org>,
	Andrew Dunstan <andrew@dunslane.net>, Bernd Helmle <mailings@oopsware.de>,
	Peter Eisentraut <peter_e@gmx.net>,
	Susanne Ebrecht <susanne.ebrecht@credativ.de>
Subject: Re: [PATCHES] 8.2 features?
References: <44B69778.5050104@dunslane.net>
	<50461.84.63.113.55.1152832991.squirrel@pezone.net>
	<ECCAAC0A3182895D3D12B0E8@[172.26.14.247]>
	<44B7ADFC.90205@dunslane.net> <44BC0432.3040509@joeconway.com>
	<44BC661F.80609@joeconway.com> <44BCD06C.3060409@calorieking.com>
	<44BCF1D4.3010807@dunslane.net> <5842.1153246741@sss.pgh.pa.us>
	<44BD8854.9060506@calorieking.com> <15212.1153279954@sss.pgh.pa.us>
	<44BDB2F5.7080003@joeconway.com> <44BEA710.6060700@joeconway.com>
	<23198.1153367887@sss.pgh.pa.us> <44BF0382.2010501@joeconway.com>
	<23454.1153370214@sss.pgh.pa.us>
In-Reply-To: <23454.1153370214@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200607/874
X-Sequence-Number: 86729

Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
> 
>>The difficulty is finding a way to avoid all that extra work without a 
>>very ugly special case kludge just for inserts.
> 
> [ thinks a bit ... ]
> 
> It seems to me that the reason it's painful is exactly that INSERT
> ... VALUES is a kluge already.  We've special-cased the situation where
> the INSERT's <query expression> is a <table value constructor> with
> exactly one row --- but actually a <table value constructor> with
> multiple rows ought to be allowed anywhere you can currently write
> "SELECT ...".  So ideally fixing this would include eliminating the
> current artificial distinction between two types of INSERT command.
> 
> I think the place we'd ultimately like to get to involves changing the
> executor's Result node type to have a list of targetlists and sequence
> through those lists to produce its results

I was actually just looking at that and ended up thinking that it might 
be better to deal with it one level down in ExecProject (because it is 
already passing targetlists directly to ExecTargetList).

> That part seems clear, what's a bit less clear is what the
> ripple effect on the upstream parser/planner data structures should be.
> Should *all* occurrences of Query be changed to have a
> list-of-targetlists?  Sounds ugly, and I don't understand what it would
> mean for any Query other than one representing a VALUES construct.

There are certainly many places to be looked at if Query.targetList 
becomes a list-of-targetlists (about 153 if I grep'd correctly).

> 
> [ thinks some more ... ]
> 
> Maybe the right place to put the list-of-targetlists functionality is
> not in Query per se, but in a new type of jointree node.  This would
> localize the impact as far as changing the datastructures go, but I've
> not thought hard enough about what the impact would actually be.

OK. You've given me a good bit to think about -- thanks!

Joe