> If you don't mind my asking, just what are the difficulties? Bruce
> mentioned the optimizer. I noticed the executor code that does
> merge joins has conditionalized stuff in it to insert the nulls
> required by outer join. And the parser has conditionalized stuff
> to deal with them.
The conditional stuff is from my poking at it over the last few
months. OK, the difficulties are (I'll probably leave something out):
1) The parser is written to handle the traditional inner join syntax,
which separates the FROM and WHERE clauses into two distinct pieces.
The outer join syntax (which of course can also do inner joins) has
qualifiers and table and column "aliases" buried down in the FROM
clause, and it is a pain to percolate that back up as it is
transformed by the parser backend.
2) The optimizer usually feels free to try every combination of inner
joins, since they are completely transitive. But outer joins are not:
they need to be done in a specific order since the *absence* of a
match is significant.
3) The executor needs to understand how to expand a left- or
right-side tuple into a null-filled result. I've played with the
mergejoin code and have taught it to walk the tables correctly, but it
needs code added which actually generates the result tuple. And the
other join methods don't know anything about outer joins yet.
Enough?
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California