Perform RLS WITH CHECK before constraints, etc

The RLS capability is built on top of the WITH CHECK OPTION
system which was added for auto-updatable views, however, unlike
WCOs on views (which are mandated by the SQL spec to not fire until
after all other constraints and checks are done), it makes much more
sense for RLS checks to happen earlier than constraint and uniqueness
checks.

This patch reworks the structure which holds the WCOs a bit to be
explicitly either VIEW or RLS checks and the RLS-related checks are
done prior to the constraint and uniqueness checks.  This also allows
better error reporting as we are now reporting when a violation is due
to a WITH CHECK OPTION and when it's due to an RLS policy violation,
which was independently noted by Craig Ringer as being confusing.

The documentation is also updated to include a paragraph about when RLS
WITH CHECK handling is performed, as there have been a number of
questions regarding that and the documentation was previously silent on
the matter.

Author: Dean Rasheed, with some kabitzing and comment changes by me.

1 files changed, 8 insertions, 0 deletions

diff --git a/doc/src/sgml/ref/create_policy.sgml b/doc/src/sgml/ref/create_policy.sgml
index 868a6c1cd34..49eaadc2598 100644
--- a/doc/src/sgml/ref/create_policy.sgml
+++ b/doc/src/sgml/ref/create_policy.sgml
@@ -61,6 +61,14 @@ CREATE POLICY <replaceable class="parameter">name</replaceable> ON <replaceable
   </para>
 
   <para>
+    For INSERT and UPDATE queries, WITH CHECK expressions are enforced after
+    BEFORE triggers are fired, and before any data modifications are made.
+    Thus a BEFORE ROW trigger may modify the data to be inserted, affecting
+    the result of the security policy check.  WITH CHECK expressions are
+    enforced before any other constraints.
+  </para>
+
+  <para>
    Policy names are per-table, therefore one policy name can be used for many
    different tables and have a definition for each table which is appropriate to
    that table.