create_role.sgml

PostgreSQL 8.1.4的源码 适用于Linux下的开源数据库系统

<!--
$PostgreSQL: pgsql/doc/src/sgml/ref/create_role.sgml,v 1.4.2.1 2006/03/03 03:06:17 momjian Exp $
PostgreSQL documentation
-->

<refentry id="SQL-CREATEROLE">
 <refmeta>
  <refentrytitle id="sql-createrole-title">CREATE ROLE</refentrytitle>
  <refmiscinfo>SQL - Language Statements</refmiscinfo>
 </refmeta>

 <refnamediv>
  <refname>CREATE ROLE</refname>
  <refpurpose>define a new database role</refpurpose>
 </refnamediv>

 <indexterm zone="sql-createrole">
  <primary>CREATE ROLE</primary>
 </indexterm>

 <refsynopsisdiv>
<synopsis>
CREATE ROLE <replaceable class="PARAMETER">name</replaceable> [ [ WITH ] <replaceable class="PARAMETER">option</replaceable> [ ... ] ]

where <replaceable class="PARAMETER">option</replaceable> can be:
    
      SUPERUSER | NOSUPERUSER
    | CREATEDB | NOCREATEDB
    | CREATEROLE | NOCREATEROLE
    | CREATEUSER | NOCREATEUSER
    | INHERIT | NOINHERIT
    | LOGIN | NOLOGIN
    | CONNECTION LIMIT <replaceable class="PARAMETER">connlimit</replaceable>
    | [ ENCRYPTED | UNENCRYPTED ] PASSWORD '<replaceable class="PARAMETER">password</replaceable>'
    | VALID UNTIL '<replaceable class="PARAMETER">timestamp</replaceable>' 
    | IN ROLE <replaceable class="PARAMETER">rolename</replaceable> [, ...]
    | IN GROUP <replaceable class="PARAMETER">rolename</replaceable> [, ...]
    | ROLE <replaceable class="PARAMETER">rolename</replaceable> [, ...]
    | ADMIN <replaceable class="PARAMETER">rolename</replaceable> [, ...]
    | USER <replaceable class="PARAMETER">rolename</replaceable> [, ...]
    | SYSID <replaceable class="PARAMETER">uid</replaceable> 
</synopsis>
 </refsynopsisdiv>

 <refsect1>
  <title>Description</title>

  <para>
   <command>CREATE ROLE</command> adds a new role to a
   <productname>PostgreSQL</productname> database cluster.  A role is
   an entity that can own database objects and have database privileges;
   a role can be considered a <quote>user</>, a <quote>group</>, or both
   depending on how it is used.  Refer to
   <xref linkend="user-manag"> and <xref
   linkend="client-authentication"> for information about managing
   users and authentication.  You must have <literal>CREATEROLE</>
   privilege or be a database superuser to use this command.
  </para>

  <para>
   Note that roles are defined at the database cluster
   level, and so are valid in all databases in the cluster.
  </para>
 </refsect1>

 <refsect1>
  <title>Parameters</title>

    <variablelist>
     <varlistentry>
      <term><replaceable class="parameter">name</replaceable></term>
      <listitem>
       <para>
        The name of the new role.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><literal>SUPERUSER</literal></term>
      <term><literal>NOSUPERUSER</literal></term>
      <listitem>
       <para>
        These clauses determine whether the new role is a <quote>superuser</>,
        who can override all access restrictions within the database.
        Superuser status is dangerous and should be used only when really
        needed.  You must yourself be a superuser to create a new superuser.
        If not specified,
        <literal>NOSUPERUSER</literal> is the default.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><literal>CREATEDB</></term>
      <term><literal>NOCREATEDB</></term>
      <listitem>
       <para>
        These clauses define a role's ability to create databases.  If
        <literal>CREATEDB</literal> is specified, the role being
        defined will be allowed to create new databases. Specifying
        <literal>NOCREATEDB</literal> will deny a role the ability to
        create databases. If not specified,
        <literal>NOCREATEDB</literal> is the default.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><literal>CREATEROLE</literal></term>
      <term><literal>NOCREATEROLE</literal></term>
      <listitem>
       <para>
        These clauses determine whether a role will be permitted to
        create new roles (that is, execute <command>CREATE ROLE</command>).
        A role with <literal>CREATEROLE</literal> privilege can also alter
        and drop other roles.
        If not specified,
        <literal>NOCREATEROLE</literal> is the default.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><literal>CREATEUSER</literal></term>
      <term><literal>NOCREATEUSER</literal></term>
      <listitem>
       <para>
        These clauses are an obsolete, but still accepted, spelling of
        <literal>SUPERUSER</literal> and <literal>NOSUPERUSER</literal>.
        Note that they are <emphasis>not</> equivalent to
        <literal>CREATEROLE</literal> as one might naively expect!
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><literal>INHERIT</literal></term>
      <term><literal>NOINHERIT</literal></term>
      <listitem>
       <para>
        These clauses determine whether a role <quote>inherits</> the
        privileges of roles it is a member of.
        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
        only grants the ability to <command>SET ROLE</> to that other role;
        the privileges of the other role are only available after having
        done so.
        If not specified,
        <literal>INHERIT</literal> is the default.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><literal>LOGIN</literal></term>
      <term><literal>NOLOGIN</literal></term>
      <listitem>
       <para>
        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
        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,
        <literal>NOLOGIN</literal> is the default, except when
        <command>CREATE ROLE</> is invoked through its alternate spelling
        <command>CREATE USER</>.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><literal>CONNECTION LIMIT</literal> <replaceable class="parameter">connlimit</replaceable></term>
      <listitem>
       <para>
        If role can log in, this specifies how many concurrent connections
        the role can make.  -1 (the default) means no limit.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><literal>PASSWORD</> <replaceable class="parameter">password</replaceable></term>
      <listitem>
       <para>
        Sets the role's password.  (A password is only of use for
        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.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><literal>ENCRYPTED</></term>
      <term><literal>UNENCRYPTED</></term>
      <listitem>
       <para>
        These key words control whether the password is stored
        encrypted in the system catalogs.  (If neither is specified,
        the default behavior is determined by the configuration
        parameter <xref linkend="guc-password-encryption">.)  If the
        presented password string is already in MD5-encrypted format,
        then it is stored encrypted as-is, regardless of whether
        <literal>ENCRYPTED</> or <literal>UNENCRYPTED</> is specified
        (since the system cannot decrypt the specified encrypted
        password string).  This allows reloading of encrypted
        passwords during dump/restore.
       </para>

       <para>
        Note that older clients may lack support for the MD5
        authentication mechanism that is needed to work with passwords
        that are stored encrypted.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><literal>VALID UNTIL</literal> '<replaceable class="parameter">timestamp</replaceable>'</term>
      <listitem>
       <para>
        The <literal>VALID UNTIL</literal> clause sets a date and
        time after which the role's password is no longer valid.  If
        this clause is omitted the password will be valid for all time.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><literal>IN ROLE</> <replaceable class="parameter">rolename</replaceable></term>