both will fail.  Also, the limit is never enforced for superusers.
  </para>

  <para>
   Caution must be exercised when specifying an unencrypted password
   with this command.  The password will be transmitted to the server
   in cleartext, and it might also be logged in the client's command
   history or the server log.  The command <xref
   linkend="app-createuser"/>, however, transmits
   the password encrypted.  Also, <xref linkend="app-psql"/>
   contains a command
   <command>\password</command> that can be used to safely change the
   password later.
  </para>
 </refsect1>

 <refsect1>
  <title>Examples</title>

  <para>
   Create a role that can log in, but don't give it a password:
<programlisting>
CREATE ROLE jonathan LOGIN;
</programlisting>
  </para>

  <para>
   Create a role with a password:
<programlisting>
CREATE USER davide WITH PASSWORD 'jw8s0F4';
</programlisting>
   (<command>CREATE USER</command> is the same as <command>CREATE ROLE</command> except
   that it implies <literal>LOGIN</literal>.)
  </para>

  <para>
   Create a role with a password that is valid until the end of 2004.
   After one second has ticked in 2005, the password is no longer
   valid.

<programlisting>
CREATE ROLE miriam WITH LOGIN PASSWORD 'jw8s0F4' VALID UNTIL '2005-01-01';
</programlisting>
  </para>

  <para>
   Create a role that can create databases and manage roles:
<programlisting>
CREATE ROLE admin WITH CREATEDB CREATEROLE;
</programlisting></para>
 </refsect1>

 <refsect1>
  <title>Compatibility</title>

  <para>
   The <command>CREATE ROLE</command> statement is in the SQL standard,
   but the standard only requires the syntax
<synopsis>
CREATE ROLE <replaceable class="parameter">name</replaceable> [ WITH ADMIN <replaceable class="parameter">role_name</replaceable> ]
</synopsis>
   Multiple initial administrators, and all the other options of
   <command>CREATE ROLE</command>, are
   <productname>PostgreSQL</productname> extensions.
  </para>

  <para>
   The SQL standard defines the concepts of users and roles, but it
   regards them as distinct concepts and leaves all commands defining
   users to be specified by each database implementation.  In
   <productname>PostgreSQL</productname> we have chosen to unify
   users and roles into a single kind of entity.  Roles therefore
   have many more optional attributes than they do in the standard.
  </para>

  <para>
   The behavior specified by the SQL standard is most closely approximated
   creating SQL-standard users as <productname>PostgreSQL</productname>
   roles with the <literal>NOINHERIT</literal> option, and SQL-standard
   roles as <productname>PostgreSQL</productname> roles with the
   <literal>INHERIT</literal> option.
  </para>

  <para>
   The <literal>USER</literal> clause has the same behavior as
   <literal>ROLE</literal> but has been deprecated:
<synopsis>
USER <replaceable class="parameter">role_name</replaceable> [, ...]
</synopsis>
  </para>

  <para>
   The <literal>IN GROUP</literal> clause has the same behavior as <literal>IN
   ROLE</literal> but has been deprecated:
<synopsis>
IN GROUP <replaceable class="parameter">role_name</replaceable> [, ...]
</synopsis>
  </para>
 </refsect1>

 <refsect1>
  <title>See Also</title>

  <simplelist type="inline">
   <member><xref linkend="sql-set-role"/></member>
   <member><xref linkend="sql-alterrole"/></member>
   <member><xref linkend="sql-droprole"/></member>
   <member><xref linkend="sql-grant"/></member>
   <member><xref linkend="sql-revoke"/></member>
   <member><xref linkend="app-createuser"/></member>
   <member><xref linkend="guc-createrole-self-grant"/></member>
  </simplelist>
 </refsect1>
</refentry>