First cut at OUTER JOINs committed

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-select in FROM
so that a view can be translated to a subselect. I'm going to work
on that next. If it seems too hard for 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 if inherited table is used
inside an outer join. Must do the Append plan at bottom level, not top,
in that case. Probably means 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 ever be supported
efficiently.

regards, tom lane