aboutsummaryrefslogtreecommitdiff
path: root/doc/src
diff options
context:
space:
mode:
authorStephen Frost <sfrost@snowman.net>2014-04-12 21:04:58 -0400
committerStephen Frost <sfrost@snowman.net>2014-04-12 21:04:58 -0400
commit842faa714c0454d67e523f5a0b6df6500e9bc1a5 (patch)
tree1c65cbddbcf8ad84a8a5985a846f78622bac5f26 /doc/src
parent9d229f399e87d2ae7132c2e8feef317ce1479728 (diff)
downloadpostgresql-842faa714c0454d67e523f5a0b6df6500e9bc1a5.tar.gz
postgresql-842faa714c0454d67e523f5a0b6df6500e9bc1a5.zip
Make security barrier views automatically updatable
Views which are marked as security_barrier must have their quals applied before any user-defined quals are called, to prevent user-defined functions from being able to see rows which the security barrier view is intended to prevent them from seeing. Remove the restriction on security barrier views being automatically updatable by adding a new securityQuals list to the RTE structure which keeps track of the quals from security barrier views at each level, independently of the user-supplied quals. When RTEs are later discovered which have securityQuals populated, they are turned into subquery RTEs which are marked as security_barrier to prevent any user-supplied quals being pushed down (modulo LEAKPROOF quals). Dean Rasheed, reviewed by Craig Ringer, Simon Riggs, KaiGai Kohei
Diffstat (limited to 'doc/src')
-rw-r--r--doc/src/sgml/ref/create_view.sgml19
1 files changed, 13 insertions, 6 deletions
diff --git a/doc/src/sgml/ref/create_view.sgml b/doc/src/sgml/ref/create_view.sgml
index 57bfae30849..a13f1cbde35 100644
--- a/doc/src/sgml/ref/create_view.sgml
+++ b/doc/src/sgml/ref/create_view.sgml
@@ -323,12 +323,6 @@ CREATE VIEW vista AS SELECT text 'Hello World' AS hello;
or set-returning functions.
</para>
</listitem>
-
- <listitem>
- <para>
- The view must not have the <literal>security_barrier</> property.
- </para>
- </listitem>
</itemizedlist>
</para>
@@ -362,6 +356,19 @@ CREATE VIEW vista AS SELECT text 'Hello World' AS hello;
</para>
<para>
+ If an automatically updatable view is marked with the
+ <literal>security_barrier</> property then all the view's <literal>WHERE</>
+ conditions (and any conditions using operators which are marked as LEAKPROOF)
+ will always be evaluated before any conditions that a user of the view has
+ added. See <xref linkend="rules-privileges"> for full details. Note that,
+ due to this, rows which are not ultimately returned (because they do not
+ pass the user's <literal>WHERE</> conditions) may still end up being locked.
+ <command>EXPLAIN</command> can be used to see which conditions are
+ applied at the relation level (and therefore do not lock rows) and which are
+ not.
+ </para>
+
+ <para>
A more complex view that does not satisfy all these conditions is
read-only by default: the system will not allow an insert, update, or
delete on the view. You can get the effect of an updatable view by