> Bruce Momjian wrote:
> >
> > > Will apply ... some other changes laying a bit of
> > > groundwork for outer joins so you can start on the planner/optimizer
> > > parts :)
> > Those will be a synch now that I understand the optimizer. In fact, I
> > think it all will happen in the executor.
>
> I've modified executor/nodeMergeJoin.c to walk a left/right/both outer
> join, but didn't fill in the part which actually creates the result
> tuple (which will be the current left- or right-side tuple plus nulls
> for filler). I hope this is up your alley :)
Nested loop and hash have to be done too.
>
> So far, I'm not certain what to pass to the planner. The syntax leads me
> to pass a select structure from gram.y with a "JoinExpr" structure in
> the "fromClause" list. I need to expand that with a combination of
> column names and qualifications, but at the time I see the JoinExpr I
> don't have access to the top query structure itself. So I may just keep
> a modestly transformed JoinExpr to expand later or to pass to the
> planner.
Can we just set a flag in the RangeTblEntry to indicate if it is an
OUTER join?
> btw, the EXCEPT/INTERSECT stuff from Stefan has some ugliness in gram.y
> which needs to be fixed (the shift/reduce conflict is not acceptable for
> our release version) and some of that code clearly needs to move to
> analyze.c or some other module.
Yes. I agree. Got Vadim's stuff merged into Stephan's code. I think a
review of the actual patch is the only solution. It is in the patches list.
-- 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