Liam Stewart <liams@redhat.com> writes:
> While it
> should be possible to modify the Result node to handle multiple
> tuples, I would rather not use Result as Result is also used for
> constant qualifications.
If you don't want to extend Result, I'd suggest generating a plan that
is an Append of Result nodes. There's no need to add a new node type.
Personally I wouldn't have a problem with allowing Result to handle
a list of targetlists, though. It's already capable of returning
multiple rows (when there's a function-returning-set in the targetlist)
so I don't find multiple targetlists to be that much of an uglification.
> Also, at some point, it would be nice to put together a new statement
> node type that represents the SQL <query expression>. This node would
> be used everywhere that a <query expression> could be used, hiding
> the complexity of having to deal with either a SELECT statement or a
> VALUES clause. For example, the parser rule for INSERT statements
> would be simplified as well as the transformInsertStmt function.
The present handling of INSERT/SELECT is really really ugly. The whole
querytree structure desperately needs to be rethought, actually. You
can find some theorizing about what to do in the mail list archives,
but we're still far from having a detailed plan.
regards, tom lane
