docs: Fix up some out-of-date references to INHERIT/NOINHERIT.

Commit e3ce2de09d814f8770b2e3b3c152b7671bcdb83f should have updated
these sections of the documentation, but failed to do so.

Patch by me, reviewed by Nathan Bossart.

Discussion: http://postgr.es/m/CA+TgmoaKMnde2W_=u7CqeCKi=FKnfbNQPwOR=c_3c8qD7b2nhQ@mail.gmail.com

diff --git a/doc/src/sgml/ref/set_role.sgml b/doc/src/sgml/ref/set_role.sgml
index 4e02322158a34f42647bd196bf6f9bfacbe6692e..deecfe4120b87e240c3204af64546352bbfc46c4 100644 (file)
--- a/doc/src/sgml/ref/set_role.sgml
+++ b/doc/src/sgml/ref/set_role.sgml
@@ -71,15 +71,16 @@ RESET ROLE
 
   <para>
    Using this command, it is possible to either add privileges or restrict
-   one's privileges.  If the session user role has the <literal>INHERIT</literal>
-   attribute, then it automatically has all the privileges of every role that
-   it could <command>SET ROLE</command> to; in this case <command>SET ROLE</command>
-   effectively drops all the privileges assigned directly to the session user
-   and to the other roles it is a member of, leaving only the privileges
-   available to the named role.  On the other hand, if the session user role
-   has the <literal>NOINHERIT</literal> attribute, <command>SET ROLE</command> drops the
-   privileges assigned directly to the session user and instead acquires the
-   privileges available to the named role.
+   one's privileges.  If the session user role has been granted memberships
+   <literal>WITH INHERIT TRUE</literal>, it automatically has all the
+   privileges of every such role. In this case, <command>SET ROLE</command>
+   effectively drops all the privileges except for those which the target role
+   directly possesses or inherits.  On the other hand, if the session user role
+   has been granted memberships <literal>WITH INHERIT FALSE</literal>, the
+   privileges of the granted roles can't be accessed by default. However, the
+   session user can use <command>SET ROLE</command> to drop the privileges
+   assigned directly to the session user and instead acquire the privileges
+   available to the named role.
   </para>
 
   <para>

diff --git a/doc/src/sgml/user-manag.sgml b/doc/src/sgml/user-manag.sgml
index 54cb253d95e11f3118898be840ff0dd4a07760ec..9b1f002d1bb37923eb723d5254e8395bec907b14 100644 (file)
--- a/doc/src/sgml/user-manag.sgml
+++ b/doc/src/sgml/user-manag.sgml
@@ -241,9 +241,12 @@ CREATE USER <replaceable>name</replaceable>;
       <term>inheritance of privileges<indexterm><primary>role</primary><secondary>privilege to inherit</secondary></indexterm></term>
       <listitem>
        <para>
-        A role is given permission to inherit the privileges of roles it is a
-        member of, by default. However, to create a role without the permission,
-        use <literal>CREATE ROLE <replaceable>name</replaceable> NOINHERIT</literal>.
+        A role inherits the privileges of roles it is a member of, by default.
+        However, to create a role which does not inherit privileges by
+        default, use <literal>CREATE ROLE <replaceable>name</replaceable>
+        NOINHERIT</literal>.  Alternatively, inheritance can be overriden
+        for individual grants by using <literal>WITH INHERIT TRUE</literal>
+        or <literal>WITH INHERIT FALSE</literal>.
        </para>
       </listitem>
      </varlistentry>
@@ -357,16 +360,17 @@ REVOKE <replaceable>group_role</replaceable> FROM <replaceable>role1</replaceabl
    database session has access to the privileges of the group role rather
    than the original login role, and any database objects created are
    considered owned by the group role not the login role.  Second, member
-   roles that have the <literal>INHERIT</literal> attribute automatically have use
-   of the privileges of roles of which they are members, including any
+   roles that have the been granted membership with the
+   <literal>INHERIT</literal> option automatically have use
+   of the privileges of those roles, including any
    privileges inherited by those roles.
    As an example, suppose we have done:
 <programlisting>
-CREATE ROLE joe LOGIN INHERIT;
-CREATE ROLE admin NOINHERIT;
-CREATE ROLE wheel NOINHERIT;
-GRANT admin TO joe;
-GRANT wheel TO admin;
+CREATE ROLE joe LOGIN;
+CREATE ROLE admin;
+CREATE ROLE wheel;
+GRANT admin TO joe WITH INHERIT TRUE;
+GRANT wheel TO admin WITH INHERIT FALSE;
 </programlisting>
    Immediately after connecting as role <literal>joe</literal>, a database
    session will have use of privileges granted directly to <literal>joe</literal>
@@ -374,8 +378,8 @@ GRANT wheel TO admin;
    <quote>inherits</quote> <literal>admin</literal>'s privileges.  However, privileges
    granted to <literal>wheel</literal> are not available, because even though
    <literal>joe</literal> is indirectly a member of <literal>wheel</literal>, the
-   membership is via <literal>admin</literal> which has the <literal>NOINHERIT</literal>
-   attribute.  After:
+   membership is via <literal>admin</literal> which was granted using
+   <literal>WITH INHERIT FALSE</literal>. After:
 <programlisting>
 SET ROLE admin;
 </programlisting>