]> granicus.if.org Git - postgresql/commit
Fix usage of whole-row variables in WCO and RLS policy expressions.
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 12 Sep 2019 22:29:18 +0000 (18:29 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 12 Sep 2019 22:29:49 +0000 (18:29 -0400)
commitb54cff2bf32d6de65ba2e215ad301d8daef35c17
tree8d9981ba5659b474780743eb24f6a76b2f31f88b
parent603a28b4497347bc0a4ff1dbea3bb6d1e04d740c
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-99290d2e4642cbd5@postgresql.org
Discussion: https://postgr.es/m/20181205225213.hiwa3kgoxeybqcqv@alap3.anarazel.de
src/backend/executor/nodeModifyTable.c
src/test/regress/expected/rowsecurity.out
src/test/regress/expected/updatable_views.out
src/test/regress/sql/rowsecurity.sql