> > ... represent general subqueries or intermediate queries in the
> > parse tree.
> Maybe it's time to bite the bullet and do it. You have any thoughts
> on what the representation should look like?
I was hoping you would tell me ;)
I don't have a good feel for the current parse tree (which of course
hasn't kept me from fooling around with it). But I'll definitely need
something extra or different to implement outer joins. If I were
keeping everything else the same, I was thinking of propagating a
"join expression" into the planner/optimizer in the same area as the
existing qualification nodes. One of the differences would be that the
JE marks a node around which the optimizer is not allowed to reorder
the plan (since outer joins must be evaluated in a specific order to
get the right result). But I could just as easily represent this as a
subquery node somewhere else in the parse tree.
afaik the planner/optimizer already has the notion of
merging/joining/scanning intermediate results, so teaching it to
invoke these explicitly from the query tree rather than just
implicitly may not be a huge stretch.
btw I'm currently rewriting the join syntax in gram.y to conform
better to a closer reading of the SQL92 standard. One annoyance is
that the standard allows table *and* column aliasing *everywhere*.
e.g.
select * from (t1 as x1 (i,j,k) join t2 using (i)) as r1 (a,b,c,d)
is (apparently) legal syntax, resulting in rows labeled a-d. Ugh.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
