Kevin O'Gorman pointed out to me that this example fails in current
sources:
select a from foo union all (select b from foo except select a from foo);
The problem is that the result of the EXCEPT has a resjunk column (which
is added by the EXCEPT code so that it can tell lefthand input rows from
righthand input rows in its merged-and-sorted datastream). But the
result of the leftmost SELECT doesn't. The UNION ALL part is done by
a simple Append plan, which means that one of Append's inputs has just
the desired data while the other one has the data plus a resjunk column.
As things stand, the Append blindly claims that its result targetlist
is the same as its first input plan --- so execMain doesn't see any junk
columns, doesn't run a junk-column-removal filter, and when the tuples
with junk in them hit the printtup stage, everything goes to pieces.
A quick and dirty hack that would fix this (or at least this example)
is to make Append return the longest of its subplan targetlists rather
than the first one. execMain doesn't especially care what the junk
columns are stated to be, just whether there are any.
I think a cleaner fix in the long run would be to pull out junkfiltering
from the executor top level and make it a plan node type (in fact, it's
likely that we don't even need a new plan node type; Result could
compute the cleaned-up targetlist just fine). Then the junk columns
could be removed individually from the subplans of Append, leaving clean
data coming out. However, I don't really have time to do that for 7.1.
More generally, this example points up what may be a death blow for
Chris Bitmead's hopes of having a query that can return all the columns
out of each subclass of an inheritance hierarchy. If we can't safely
return varying tuple structures from an Append, that's never gonna work.
But the whole concept of plan nodes with associated targetlists seems
to depend on the assumption of fixed tuple structures passing through
any one plan level.
Comments, better ideas?
regards, tom lane
