Remove the row_security=force GUC value.

Every query of a single ENABLE ROW SECURITY table has two meanings, with
the row_security GUC selecting between them.  With row_security=force
available, every function author would have been advised to either set
the GUC locally or test both meanings.  Non-compliance would have
threatened reliability and, for SECURITY DEFINER functions, security.
Authors already face an obligation to account for search_path, and we
should not mimic that example.  With this change, only BYPASSRLS roles
need exercise the aforementioned care.  Back-patch to 9.5, where the
row_security GUC was introduced.

Since this narrows the domain of pg_db_role_setting.setconfig and
pg_proc.proconfig, one might bump catversion.  A row_security=force
setting in one of those columns will elicit a clear message, so don't.

2 files changed, 9 insertions, 21 deletions

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index c11ae47b84c..c8ec219ffc6 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -5541,10 +5541,8 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
         to queries which are run against tables that have row security enabled.
         The default is <literal>on</>.  When set to <literal>on</>, all users,
         except superusers and the owner of the table, will have the row
-        policies for the table applied to their queries. The table owner and
-        superuser can request that row policies be applied to their queries by
-        setting this to <literal>force</>. Lastly, this can also be set to
-        <literal>off</> which will bypass row policies for the table, if
+        policies for the table applied to their queries.  When set to
+        <literal>off</>, queries will bypass row policies for the table, if
         possible, and error if not.
        </para>
 
@@ -5558,13 +5556,6 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
        </para>
 
        <para>
-        The allowed values of <varname>row_security</> are
-        <literal>on</> (apply normally - not to superuser or table owner),
-        <literal>off</> (fail if row security would be applied), and
-        <literal>force</> (apply always - even to superuser and table owner).
-       </para>
-
-       <para>
         For more information on row security policies,
         see <xref linkend="SQL-CREATEPOLICY">.
        </para>
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index e4e6b5cff4a..e9499d3a429 100644
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -1585,16 +1585,13 @@ REVOKE ALL ON accounts FROM PUBLIC;
 
   <para>
    The table owners and superusers bypass the row security system when
-   querying a table, by default.  Row security can be enabled for
-   superusers and table owners by setting
-   <xref linkend="guc-row-security"> to <literal>force</literal>.  Any
-   user can request that row security be bypassed by setting
-   <xref linkend="guc-row-security"> to <literal>off</literal>.  If
-   the user does not have privileges to bypass row security when
-   querying a given table then an error will be returned instead.  Other
-   users can be granted the ability to bypass the row security system
-   with the <literal>BYPASSRLS</literal> role attribute.  This
-   attribute can only be set by a superuser.
+   querying a table.  Any user can request that row security be bypassed by
+   setting <xref linkend="guc-row-security"> to <literal>off</literal>.  If
+   the user does not have privileges to bypass row security when querying a
+   given table then an error will be returned instead.  Other users can be
+   granted the ability to bypass the row security system with
+   the <literal>BYPASSRLS</literal> role attribute.  This attribute can only
+   be set by a superuser.
   </para>
 
   <para>