BTW, one other point for the archives, before I forget it: it'd probably
also be wise to change the parser's output representation of set
operations. I think it should create a separate RTE entry corresponding
to each SetOperation node, similar to what we do for explicit JOIN
nodes. Then there is a clean representation for Vars referencing the
setop outputs: they can use the RT index of the SetOp RTE entry.
The current implementation is that all Vars in the upper query use the
RTI of the leftmost leaf query of the setop structure, which is really
bogus. First, that query doesn't necessarily output the same datatypes
as the upper setops do, so the datatypes shown by the Vars don't always
match the RTE they claim to refer to. (This is one reason why all of
the setop optimizations we do have tend to punt as soon as any datatype
changes occur.) Second, this design provides no good way to refer to
outputs of intermediate setops. I think we will *have* to fix that if
we want to make the planner's handling of these cases much smarter than
it is now.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
