From: Joe Conway <mail@joeconway.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Christopher Kings-Lynne <chris.kings-lynne@calorieking.com>
Cc: Hackers (PostgreSQL) <pgsql-hackers@postgresql.org>
Cc: Andrew Dunstan <andrew@dunslane.net>
Cc: Bernd Helmle <mailings@oopsware.de>
Cc: Peter Eisentraut <peter_e@gmx.net>
Cc: Susanne Ebrecht <susanne.ebrecht@credativ.de>
Subject: Re: [PATCHES] 8.2 features?
Date: Wed, 19 Jul 2006 22:18:39 -0700
Message-ID: <44BF122F.1080200@joeconway.com> (raw)
In-Reply-To: <23454.1153370214@sss.pgh.pa.us>
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-docs@postgresql.org
Cc: mail@joeconway.com, tgl@sss.pgh.pa.us, chris.kings-lynne@calorieking.com, pgsql-hackers@postgresql.org, andrew@dunslane.net, mailings@oopsware.de, peter_e@gmx.net, susanne.ebrecht@credativ.de
Subject: Re: [PATCHES] 8.2 features?
In-Reply-To: <44BF122F.1080200@joeconway.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox