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>

    A role's attributes can be modified after creation with
    <command>ALTER ROLE</command>.<indexterm><primary>ALTER ROLE</primary></indexterm>
    See the reference pages for the <xref linkend="sql-createrole"/>
    and <xref linkend="sql-alterrole"/> commands for details.
   </para>

  <para>
   A role can also have role-specific defaults for many of the run-time
   configuration settings described in <xref
   linkend="runtime-config"/>.  For example, if for some reason you
   want to disable index scans (hint: not a good idea) anytime you
   connect, you can use:
<programlisting>
ALTER ROLE myname SET enable_indexscan TO off;
</programlisting>
   This will save the setting (but not set it immediately).  In
   subsequent connections by this role it will appear as though
   <literal>SET enable_indexscan TO off</literal> had been executed
   just before the session started.
   You can still alter this setting during the session; it will only
   be the default. To remove a role-specific default setting, use
   <literal>ALTER ROLE <replaceable>rolename</replaceable> RESET <replaceable>varname</replaceable></literal>.
   Note that role-specific defaults attached to roles without
   <literal>LOGIN</literal> privilege are fairly useless, since they will never
   be invoked.
  </para>

  <para>
   When a non-superuser creates a role using the <literal>CREATEROLE</literal>
   privilege, the created role is automatically granted back to the creating
   user, just as if the bootstrap superuser had executed the command
   <literal>GRANT created_user TO creating_user WITH ADMIN TRUE, SET FALSE,
   INHERIT FALSE</literal>. Since a <literal>CREATEROLE</literal> user can
   only exercise special privileges with regard to an existing role if they
   have <literal>ADMIN OPTION</literal> on it, this grant is just sufficient
   to allow a <literal>CREATEROLE</literal> user to administer the roles they
   created. However, because it is created with <literal>INHERIT FALSE, SET
   FALSE</literal>, the <literal>CREATEROLE</literal> user doesn't inherit the
   privileges of the created role, nor can it access the privileges of that
   role using <literal>SET ROLE</literal>. However, since any user who has
   <literal>ADMIN OPTION</literal> on a role can grant membership in that
   role to any other user, the <literal>CREATEROLE</literal> user can gain
   access to the created role by simply granting that role back to
   themselves with the <literal>INHERIT</literal> and/or <literal>SET</literal>
   options. Thus, the fact that privileges are not inherited by default nor
   is <literal>SET ROLE</literal> granted by default is a safeguard against
   accidents, not a security feature. Also note that, because this automatic
   grant is granted by the bootstrap superuser, it cannot be removed or changed by
   the <literal>CREATEROLE</literal> user; however, any superuser could
   revoke it, modify it, and/or issue additional