<literal>SUPERUSER</literal> roles that already exist.
        Furthermore, <literal>CREATEROLE</literal> does not convey the power
        to create <literal>REPLICATION</literal> users, nor the ability to
        grant or revoke the <literal>REPLICATION</literal> privilege, nor the
        ability to modify the role properties of such users.  However, it does
        allow <literal>ALTER ROLE ... SET</literal> and
        <literal>ALTER ROLE ... RENAME</literal> to be used on
        <literal>REPLICATION</literal> roles, as well as the use of
        <literal>COMMENT ON ROLE</literal>,
        <literal>SECURITY LABEL ON ROLE</literal>,
        and <literal>DROP ROLE</literal>.
        Finally, <literal>CREATEROLE</literal> does not
        confer the ability to grant or revoke the <literal>BYPASSRLS</literal>
        privilege.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>initiating replication<indexterm><primary>role</primary><secondary>privilege to initiate replication</secondary></indexterm></term>
      <listitem>
       <para>
        A role must explicitly be given permission to initiate streaming
        replication (except for superusers, since those bypass all permission
        checks). A role used for streaming replication must
        have <literal>LOGIN</literal> permission as well. To create such a role, use
        <literal>CREATE ROLE <replaceable>name</replaceable> REPLICATION
        LOGIN</literal>.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>password<indexterm><primary>password</primary></indexterm></term>
      <listitem>
       <para>
        A password is only significant if the client authentication
        method requires the user to supply a password when connecting
        to the database. The <option>password</option> and
        <option>md5</option> authentication methods
        make use of passwords. Database passwords are separate from
        operating system passwords. Specify a password upon role
        creation with <literal>CREATE ROLE
        <replaceable>name</replaceable> PASSWORD '<replaceable>string</replaceable>'</literal>.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>inheritance of privileges<indexterm><primary>role</primary><secondary>privilege to inherit</secondary></indexterm></term>
      <listitem>
       <para>
        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 overridden
        for individual grants by using <literal>WITH INHERIT TRUE</literal>
        or <literal>WITH INHERIT FALSE</literal>.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>bypassing row-level security<indexterm><primary>role</primary><secondary>privilege to bypass</secondary></indexterm></term>
      <listitem>
       <para>
        A role must be explicitly given permission to bypass every row-level security (RLS) policy
        (except for superusers, since those bypass all permission checks).
        To create such a role, use <literal>CREATE ROLE <replaceable>name</replaceable> BYPASSRLS</literal> as a superuser.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>connection limit<indexterm><primary>role</primary><secondary>privilege to limit connection</secondary></indexterm></term>
      <listitem>
       <para>
        Connection limit can specify how many concurrent connections a role can make.
        -1 (the default) means no limit. Specify connection limit upon role creation with
        <literal>CREATE ROLE <replaceable>name</replaceable> CONNECTION LIMIT '<replaceable>integer</replaceable>'</literal>.
       </para>
      </listitem>
     </varlistentry>
    </variablelist>