<para>
   To determine the set of existing roles, examine the <structname>pg_roles</structname>
   system catalog, for example:
<synopsis>
SELECT rolname FROM pg_roles;
</synopsis>
   or to see just those capable of logging in:
<synopsis>
SELECT rolname FROM pg_roles WHERE rolcanlogin;
</synopsis>
   The <xref linkend="app-psql"/> program's <literal>\du</literal> meta-command
   is also useful for listing the existing roles.
  </para>

  <para>
   In order to bootstrap the database system, a freshly initialized
   system always contains one predefined login-capable role. This role
   is always a <quote>superuser</quote>, and it will have
   the same name as the operating system user that initialized the
   database cluster with <command>initdb</command> unless a different name
   is specified.  This role is often named
   <literal>postgres</literal>. In order to create more roles you
   first have to connect as this initial role.
  </para>

  <para>
   Every connection to the database server is made using the name of some
   particular role, and this role determines the initial access privileges for
   commands issued in that connection.
   The role name to use for a particular database
   connection is indicated by the client that is initiating the
   connection request in an application-specific fashion. For example,
   the <command>psql</command> program uses the
   <option>-U</option> command line option to indicate the role to
   connect as.  Many applications assume the name of the current
   operating system user by default (including
   <command>createuser</command> and <command>psql</command>).  Therefore it
   is often convenient to maintain a naming correspondence between
   roles and operating system users.
  </para>

  <para>
   The set of database roles a given client connection can connect as
   is determined by the client authentication setup, as explained in
   <xref linkend="client-authentication"/>. (Thus, a client is not
   limited to connect as the role matching
   its operating system user, just as a person's login name
   need not match his or her real name.)  Since the role
   identity determines the set of privileges available to a connected
   client, it is important to carefully configure privileges when setting up
   a multiuser environment.
  </para>
 </sect1>

 <sect1 id="role-attributes">
  <title>Role Attributes</title>

   <para>
    A database role can have a number of attributes that define its
    privileges and interact with the client authentication system.

    <variablelist>
     <varlistentry>
      <term>login privilege<indexterm><primary>login privilege</primary></indexterm></term>
      <listitem>
       <para>
        Only roles that have the <literal>LOGIN</literal> attribute can be used
        as the initial role name for a database connection.  A role with
        the <literal>LOGIN</literal> attribute can be considered the same
        as a <quote>database user</quote>.  To create a role with login privilege,
        use either:
<programlisting>
CREATE ROLE <replaceable>name</replaceable> LOGIN;
CREATE USER <replaceable>name</replaceable>;
</programlisting>
        (<command>CREATE USER</command> is equivalent to <command>CREATE ROLE</command>
        except that <command>CREATE USER</command> includes <literal>LOGIN</literal> by
        default, while <command>CREATE ROLE</command> does not.)
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>superuser status<indexterm><primary>superuser</primary></indexterm></term>
      <listitem>
       <para>
        A database superuser bypasses all permission checks, except the right
        to log in.  This is a dangerous privilege and should not be used
        carelessly; it is best to do most of your work as a role that is not a
        superuser.  To create a new database superuser, use <literal>CREATE
        ROLE <replaceable>name</replaceable> SUPERUSER</literal>.  You must do
        this as a