OSDN Git Service

Repair planner bug introduced in 8.2 by ability to rearrange outer joins:
authorTom Lane <tgl@sss.pgh.pa.us>
Tue, 22 May 2007 23:23:58 +0000 (23:23 +0000)
committerTom Lane <tgl@sss.pgh.pa.us>
Tue, 22 May 2007 23:23:58 +0000 (23:23 +0000)
commit11086f2f2bfec3a5fd37daf3c2e44b51abaf9b69
treefe6813c101615ad453da5dc56acf0c3f74caa94a
parent0f6e2d085de7fc62e6478d5bd92c03a31da729f6
Repair planner bug introduced in 8.2 by ability to rearrange outer joins:
in cases where a sub-SELECT inserts a WHERE clause between two outer joins,
that clause may prevent us from re-ordering the two outer joins.  The code
was considering only the joins' own ON-conditions in determining reordering
safety, which is not good enough.  Add a "delay_upper_joins" flag to
OuterJoinInfo to flag that we have detected such a clause and higher-level
outer joins shouldn't be permitted to commute with this one.  (This might
seem overly coarse, but given the current rules for OJ reordering, it's
sufficient AFAICT.)

The failure case is actually pretty narrow: it needs a WHERE clause within
the RHS of a left join that checks the RHS of a lower left join, but is not
strict for that RHS (else we'd have simplified the lower join to a plain
join).  Even then no failure will be manifest unless the planner chooses to
rearrange the join order.

Per bug report from Adam Terrey.
src/backend/nodes/copyfuncs.c
src/backend/nodes/equalfuncs.c
src/backend/nodes/outfuncs.c
src/backend/optimizer/plan/initsplan.c
src/include/nodes/relation.h
src/test/regress/expected/join.out
src/test/regress/expected/join_1.out
src/test/regress/sql/join.sql