diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2019-02-22 12:23:00 -0500 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2019-02-22 12:23:21 -0500 |
commit | 58947fbd56d1481a86a03087c81f728fdf0be866 (patch) | |
tree | 56ada5d3f825aec386a8003b69ef3770e4a76eb7 /src/backend/lib/knapsack.c | |
parent | 398cc6fb93814423f205dee435d1a174068c041a (diff) | |
download | postgresql-58947fbd56d1481a86a03087c81f728fdf0be866.tar.gz postgresql-58947fbd56d1481a86a03087c81f728fdf0be866.zip |
Fix plan created for inherited UPDATE/DELETE with all tables excluded.
In the case where inheritance_planner() finds that every table has
been excluded by constraints, it thought it could get away with
making a plan consisting of just a dummy Result node. While certainly
there's no updating or deleting to be done, this had two user-visible
problems: the plan did not report the correct set of output columns
when a RETURNING clause was present, and if there were any
statement-level triggers that should be fired, it didn't fire them.
Hence, rather than only generating the dummy Result, we need to
stick a valid ModifyTable node on top, which requires a tad more
effort here.
It's been broken this way for as long as inheritance_planner() has
known about deleting excluded subplans at all (cf commit 635d42e9c),
so back-patch to all supported branches.
Amit Langote and Tom Lane, per a report from Petr Fedorov.
Discussion: https://postgr.es/m/5da6f0f0-1364-1876-6978-907678f89a3e@phystech.edu
Diffstat (limited to 'src/backend/lib/knapsack.c')
0 files changed, 0 insertions, 0 deletions