Fix usage of whole-row variables in WCO and RLS policy expressions. Since WITH CHECK OPTION was introduced, ExecInitModifyTable has initialized WCO expressions with the wrong plan node as parent -- that is, it passed its input subplan not the ModifyTable node itself. Up to now we thought this was harmless, but bug #16006 from Vinay Banakar shows it's not: if the input node is a SubqueryScan then ExecInitWholeRowVar can get confused into doing the wrong thing. (The fact that ExecInitWholeRowVar contains such logic is certainly a horrid kluge that doesn't deserve to live, but figuring out another way to do that is a task for some other day.)
Andres had already noticed the wrong-parent mistake and fixed it in commit 148e632c0, but not being aware of any user-visible consequences, he quite reasonably didn't back-patch. This patch is simply a back-patch of 148e632c0, plus addition of a test case based on bug #16006. I also added the test case to v12/HEAD, even though the bug is already fixed there. Back-patch to all supported branches. 9.4 lacks RLS policies so the new test case doesn't work there, but I'm pretty sure a test could be devised based on using a whole-row Var in a plain WITH CHECK OPTION condition. (I lack the cycles to do so myself, though.) Andres Freund and Tom Lane Discussion: https://postgr.es/m/16006-99290d2e4642c...@postgresql.org Discussion: https://postgr.es/m/20181205225213.hiwa3kgoxeybq...@alap3.anarazel.de Branch ------ REL9_4_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/ca08ea52bfbc0e02eb7e866bb05bf166f15c9b75 Modified Files -------------- src/backend/executor/nodeModifyTable.c | 2 +- src/test/regress/expected/updatable_views.out | 28 +++++++++++++-------------- 2 files changed, 15 insertions(+), 15 deletions(-)
