> >A bit of a misunderstanding here: we are using SQL92 syntax but will
> >try to implement the outer join operation using *internal* data
> >structures similar to what we have now.
>
> Yes, I've seen the existing code, in particular regarding inner
> joins.
>
> >Any alternate syntaxes are just a diversion which slow us down on the
> >road to world domination ;)
>
> That's my first feeling, too, as I hope I made clear.
>
> 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.
>
> So, is it ("just", he says :) the optimizer, or more?
OK, let me summarize where we are. Thomas is the man on this.
Thomas is doing the ANSI syntax in gram.y and passing information around
in the parser. We then need code in the executor for Merge/Hash/Nested
Loop joins to do outer joins.
The requirement in the optimizer is to have the _outer_ column always in
the left/outer position in hash/nested loop joins. Mergejoin can have
it either place. The ANSI syntax also specifies the exact join that
gets the outer, and I am not sure how to get that information/control
into the optimizer.
Thomas is now redesigning the parser _outer_ code to pass around the
outer information in a better way than his first cut at the code.
That is where we are. There are many people ready to get involved when
there is a need. I know many want this in 7.0.
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026