Re: start on outer join
От | Thomas G. Lockhart |
---|---|
Тема | Re: start on outer join |
Дата | |
Msg-id | 36D0FFA4.32ADB75C@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] 'pgsql/src/test/regress/expected rules.out' (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: start on outer join
|
Список | pgsql-hackers |
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 :) 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. 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. - Tom
В списке pgsql-hackers по дате отправления: