pgsql: Fix incorrect varlevelsup in security_barrier_replace_vars().

From: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Fix incorrect varlevelsup in security_barrier_replace_vars().
Date: 2016-02-29 12:42:20
Message-ID: E1aaN9Y-00010X-1Y@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Fix incorrect varlevelsup in security_barrier_replace_vars().

When converting an RTE with securityQuals into a security barrier
subquery RTE, ensure that the Vars in the new subquery's targetlist
all have varlevelsup = 0 so that they correctly refer to the
underlying base relation being wrapped.

The original code was creating new Vars by copying them from existing
Vars referencing the base relation found elsewhere in the query, but
failed to account for the fact that such Vars could come from sublink
subqueries, and hence have varlevelsup > 0. In practice it looks like
this could only happen with nested security barrier views, where the
outer view has a WHERE clause containing a correlated subquery, due to
the order in which the Vars are processed.

Bug: #13988
Reported-by: Adam Guthrie
Backpatch-to: 9.4, where updatable SB views were introduced

Branch
------
REL9_4_STABLE

Details
-------
http://git.postgresql.org/pg/commitdiff/9b69d5c1daeb62804eeaeab2f804191dbe0a943d

Modified Files
--------------
src/backend/optimizer/prep/prepsecurity.c | 1 +
src/test/regress/expected/updatable_views.out | 39 +++++++++++++++++++++++++++
src/test/regress/sql/updatable_views.sql | 34 +++++++++++++++++++++++
3 files changed, 74 insertions(+)

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2016-02-29 15:14:19 pgsql: Fix build under OPTIMIZER_DEBUG.
Previous Message Tom Lane 2016-02-29 04:40:56 pgsql: Avoid multiple free_struct_lconv() calls on same data.