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