doc: Make some index terms and terminology more consistent

doc/src/sgml/ddl.sgml

@@ -1512,20 +1512,11 @@ REVOKE ALL ON accounts FROM PUBLIC;
   <title>Row Security Policies</title>
 
   <indexterm zone="ddl-rowsecurity">
-   <primary>rowsecurity</primary>
+   <primary>row security</primary>
   </indexterm>
 
   <indexterm zone="ddl-rowsecurity">
-   <primary>rls</primary>
-  </indexterm>
-
-  <indexterm>
-   <primary>policies</primary>
-   <see>policy</see>
-  </indexterm>
-
-  <indexterm zone="ddl-rowsecurity">
-   <primary>POLICY</primary>
+   <primary>policy</primary>
   </indexterm>
 
   <para>

doc/src/sgml/ref/create_policy.sgml

@@ -112,7 +112,7 @@ CREATE POLICY <replaceable class="parameter">name</replaceable> ON <replaceable
    the user running the overall query.  Therefore, users who are using a given
    policy must be able to access any tables or functions referenced in the
    expression or they will simply receive a permission denied error when
-   attempting to query the RLS-enabled table.  This does not change how views
+   attempting to query the table that has row-level security enabled.  This does not change how views
    work, however.  As with normal queries and views, permission checks and
    policies for the tables which are referenced by a view will use the view
    owner's rights and any policies which apply to the view owner.

doc/src/sgml/ref/create_role.sgml

@@ -196,7 +196,7 @@ CREATE ROLE <replaceable class="PARAMETER">name</replaceable> [ [ WITH ] <replac
       <term><literal>NOBYPASSRLS</literal></term>
       <listitem>
        <para>
-        These clauses determine whether a role is allowed to bypass row-security
+        These clauses determine whether a role is allowed to bypass row-level security (RLS)
         policies.  A role having the <literal>BYPASSRLS</literal> attribute will
         be allowed to bypass row-security policies by setting
         <literal>row_security</literal> to