Update administrator's guide chapters for ROLEs patch.

doc/src/sgml/manage-ag.sgml

 <!--
-$PostgreSQL: pgsql/doc/src/sgml/manage-ag.sgml,v 2.42 2005/06/21 04:02:30 tgl Exp $
+$PostgreSQL: pgsql/doc/src/sgml/manage-ag.sgml,v 2.43 2005/08/14 23:35:37 tgl Exp $
 -->
 
 <chapter id="managing-databases">
@@ -94,7 +94,7 @@ SELECT datname FROM pg_database;
 CREATE DATABASE <replaceable>name</>;
 </synopsis>
    where <replaceable>name</> follows the usual rules for
-   <acronym>SQL</acronym> identifiers.  The current user automatically
+   <acronym>SQL</acronym> identifiers.  The current role automatically
    becomes the owner of the new database. It is the privilege of the
    owner of a database to remove it later on (which also removes all
    the objects in it, even if they have a different owner).
@@ -102,7 +102,7 @@ CREATE DATABASE <replaceable>name</>;
 
   <para>
    The creation of databases is a restricted operation. See <xref
-   linkend="user-attributes"> for how to grant permission.
+   linkend="role-attributes"> for how to grant permission.
   </para>
 
   <para>
@@ -158,18 +158,18 @@ createdb <replaceable class="parameter">dbname</replaceable>
 
   <para>
    Sometimes you want to create a database for someone else.  That
-   user should become the owner of the new database, so he can
+   role should become the owner of the new database, so he can
    configure and manage it himself.  To achieve that, use one of the
    following commands:
 <programlisting>
-CREATE DATABASE <replaceable>dbname</> OWNER <replaceable>username</>;
+CREATE DATABASE <replaceable>dbname</> OWNER <replaceable>rolename</>;
 </programlisting>
    from the SQL environment, or
 <programlisting>
-createdb -O <replaceable>username</> <replaceable>dbname</>
+createdb -O <replaceable>rolename</> <replaceable>dbname</>
 </programlisting>
    You must be a superuser to be allowed to create a database for
-   someone else.
+   someone else (that is, for a role you are not a member of).
   </para>
  </sect1>
 
@@ -327,7 +327,7 @@ ALTER DATABASE mydb SET geqo TO off;
 <synopsis>
 DROP DATABASE <replaceable>name</>;
 </synopsis>
-   Only the owner of the database (i.e., the user that created it), or
+   Only the owner of the database, or
    a superuser, can drop a database. Dropping a database removes all objects
    that were 
    contained within the database. The destruction of a database cannot

doc/src/sgml/ref/create_role.sgml

 <!--
-$PostgreSQL: pgsql/doc/src/sgml/ref/create_role.sgml,v 1.2 2005/07/31 17:19:17 tgl Exp $
+$PostgreSQL: pgsql/doc/src/sgml/ref/create_role.sgml,v 1.3 2005/08/14 23:35:38 tgl Exp $
 PostgreSQL documentation
 -->
 
@@ -141,7 +141,7 @@ where <replaceable class="PARAMETER">option</replaceable> can be:
        <para>
         These clauses determine whether a role <quote>inherits</> the
         privileges of roles it is a member of.
-        A role with <literal>INHERIT</literal> privilege can automatically
+        A role with the <literal>INHERIT</literal> attribute can automatically
         use whatever database privileges have been granted to all roles
         it is directly or indirectly a member of.
         Without <literal>INHERIT</literal>, membership in another role
@@ -162,7 +162,7 @@ where <replaceable class="PARAMETER">option</replaceable> can be:
         These clauses determine whether a role is allowed to log in;
         that is, whether the role can be given as the initial session
         authorization name during client connection.  A role having
-        <literal>LOGIN</literal> privilege can be thought of as a user.
+        the <literal>LOGIN</literal> attribute can be thought of as a user.
         Roles without this attribute are useful for managing database
         privileges, but are not users in the usual sense of the word.
         If not specified,
@@ -188,7 +188,7 @@ where <replaceable class="PARAMETER">option</replaceable> can be:
       <listitem>
        <para>
         Sets the role's password.  (A password is only of use for
-        roles having <literal>LOGIN</literal> privilege, but you can
+        roles having the <literal>LOGIN</literal> attribute, but you can
         nonetheless define one for roles without it.)
         If you do not plan to use password
         authentication you can omit this option.
@@ -325,7 +325,19 @@ where <replaceable class="PARAMETER">option</replaceable> can be:
   </para>
 
   <para>
-   <literal>INHERIT</> privilege is the default for reasons of backwards
+   The <literal>INHERIT</> attribute governs inheritance of grantable
+   privileges (that is, access privileges for database objects and role
+   memberships).  It does not apply to the special role attributes set by
+   <command>CREATE ROLE</> and <command>ALTER ROLE</>.  For example, being
+   a member of a role with <literal>CREATEDB</> privilege does not immediately
+   grant the ability to create databases, even if <literal>INHERIT</> is set;
+   it would be necessary to become that role via
+   <xref linkend="SQL-SET-ROLE" endterm="SQL-SET-ROLE-title"> before
+   creating a database.
+  </para>
+
+  <para>
+   The <literal>INHERIT</> attribute is the default for reasons of backwards
    compatibility: in prior releases of <productname>PostgreSQL</productname>,
    users always had access to all privileges of groups they were members of.
    However, <literal>NOINHERIT</> provides a closer match to the semantics