I have committed initial support for outer joins. There's still more to do,
but I was getting antsy to get back in sync with the CVS repository. Also,
I'm hoping to get other people to do some of the remaining work ;-)
What works: ISO "JOIN" syntax for INNER, LEFT, RIGHT, FULL, CROSS joins.
Table and column name aliases applied to JOIN results sort of work (see
below). All regression tests pass, including some rule cases that 7.0
gets wrong.
Things that need to be fixed before 7.1:
* Update user docs
* GEQO planner is untested, possibly broken
* Rule rewriter fails for views that are used inside JOIN clauses. Cleanest solution for this would be to implement
sub-selectin FROM so that a view can be translated to a subselect. I'm going to work on that next. If it seems too
hardfor 7.1, I'll hack up a patch instead.
* parse_clause.c should check validity of JOIN/ON condition (make sure it doesn't refer to any rels not in the JOIN)
* Scope of aliases in sub-joins needs work. For example, this fails:select * from (int4_tbl i1(a) join int4_tbl i2(b)
on(a<b)); because sub-join aliases aren't visible in the jointree when the ON condition is analyzed.
* I suspect ruleutils.c doesn't always choose an appropriate alias for displaying a variable that has multiple
aliases.
* Inheritance vs outer joins: existing scheme of repeating the whole plan for each inherited table is certainly no good
ifinherited table is used inside an outer join. Must do the Append plan at bottom level, not top, in that case.
Probablymeans we must distinguish top-join-level and not-top-level RTEs that are inherited.
I will take care of the first three of these to-do items, and I was hoping
to talk Thomas into looking at the next three. Perhaps Chris (or someone
who cares more about inheritance than I do ;-)) would like to take up the
last one.
Things I plan to leave for some future release:
* UNION JOIN is not implemented yet. Should fix in 7.2 when we redo querytrees --- UNION is too much of a mess right
now.
* FULL JOIN is only supported with mergejoinable join conditions. Not clear that non-mergejoinable join conditions can
everbe supported efficiently.
regards, tom lane