Adjust behavior of row_security GUC to match the docs.

Some time back we agreed that row_security=off should not be a way to
bypass RLS entirely, but only a way to get an error if it was being
applied.  However, the code failed to act that way for table owners.
Per discussion, this is a must-fix bug for 9.5.0.

Adjust the logic in rls.c to behave as expected; also, modify the
error message to be more consistent with the new interpretation.
The regression tests need minor corrections as well.  Also update
the comments about row_security in ddl.sgml to be correct.  (The
official description of the GUC in config.sgml is already correct.)

I failed to resist the temptation to do some other very minor
cleanup as well, such as getting rid of a duplicate extern declaration.

1 files changed, 21 insertions, 13 deletions

diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index 0ed22940da9..0e518437ae6 100644
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -1572,11 +1572,7 @@ REVOKE ALL ON accounts FROM PUBLIC;
    bypass the row security system when accessing a table.  Table owners
    normally bypass row security as well, though a table owner can choose to
    be subject to row security with <link linkend="sql-altertable">ALTER
-   TABLE ... FORCE ROW LEVEL SECURITY</>.  Even in a table with that option
-   selected, the table owner will bypass row security if the
-   <xref linkend="guc-row-security"> configuration parameter is set
-   to <literal>off</>; this setting is typically used for purposes such as
-   backup and restore.
+   TABLE ... FORCE ROW LEVEL SECURITY</>.
   </para>
 
   <para>
@@ -1607,14 +1603,6 @@ REVOKE ALL ON accounts FROM PUBLIC;
   </para>
 
   <para>
-   Referential integrity checks, such as unique or primary key constraints
-   and foreign key references, always bypass row security to ensure that
-   data integrity is maintained.  Care must be taken when developing
-   schemas and row level policies to avoid <quote>covert channel</> leaks of
-   information through such referential integrity checks.
-  </para>
-
-  <para>
    As a simple example, here is how to create a policy on
    the <literal>account</> relation to allow only members of
    the <literal>managers</> role to access rows, and only rows of their
@@ -1774,6 +1762,26 @@ UPDATE 1
 </programlisting>
 
   <para>
+   Referential integrity checks, such as unique or primary key constraints
+   and foreign key references, always bypass row security to ensure that
+   data integrity is maintained.  Care must be taken when developing
+   schemas and row level policies to avoid <quote>covert channel</> leaks of
+   information through such referential integrity checks.
+  </para>
+
+  <para>
+   In some contexts it is important to be sure that row security is
+   not being applied.  For example, when taking a backup, it could be
+   disastrous if row security silently caused some rows to be omitted
+   from the backup.  In such a situation, you can set the
+   <xref linkend="guc-row-security"> configuration parameter
+   to <literal>off</>.  This does not in itself bypass row security;
+   what it does is throw an error if any query's results would get filtered
+   by a policy.  The reason for the error can then be investigated and
+   fixed.
+  </para>
+
+  <para>
    For additional details see <xref linkend="sql-createpolicy">
    and <xref linkend="sql-altertable">.
   </para>