]> granicus.if.org Git - postgresql/commit
Fix inherited UPDATE/DELETE with UNION ALL subqueries.
authorTom Lane <tgl@sss.pgh.pa.us>
Sat, 14 Dec 2013 22:34:00 +0000 (17:34 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Sat, 14 Dec 2013 22:34:00 +0000 (17:34 -0500)
commit5d545b7ed53a8b2058c1152bd1c9ae227b3280e3
tree006d94cc119956d0561b5cc1cdbb108b84720e9c
parentd20eec82a0a07b9075154d1338dc6dc96ef8891c
Fix inherited UPDATE/DELETE with UNION ALL subqueries.

Fix an oversight in commit b3aaf9081a1a95c245fd605dcf02c91b3a5c3a29: we do
indeed need to process the planner's append_rel_list when copying RTE
subqueries, because if any of them were flattenable UNION ALL subqueries,
the append_rel_list shows which subquery RTEs were pulled up out of which
other ones.  Without this, UNION ALL subqueries aren't correctly inserted
into the update plans for inheritance child tables after the first one,
typically resulting in no update happening for those child table(s).
Per report from Victor Yegorov.

Experimentation with this case also exposed a fault in commit
a7b965382cf0cb30aeacb112572718045e6d4be7: if an inherited UPDATE/DELETE
was proven totally dummy by constraint exclusion, we might arrive at
add_rtes_to_flat_rtable with root->simple_rel_array being NULL.  This
should be interpreted as not having any RelOptInfos.  I chose to code
the guard as a check against simple_rel_array_size, so as to also
provide some protection against indexing off the end of the array.

Back-patch to 9.2 where the faulty code was added.
src/backend/optimizer/plan/planner.c
src/test/regress/expected/inherit.out
src/test/regress/sql/inherit.sql