matches only that specific role. Quoting
   a username starting with a <literal>+</literal> makes the
   <literal>+</literal> lose its special meaning.
  </para>
  <para>
   If the <replaceable>system-username</replaceable> field starts with a slash (<literal>/</literal>),
   the remainder of the field is treated as a regular expression.
   (See <xref linkend="posix-syntax-details"/> for details of
   <productname>PostgreSQL</productname>'s regular expression syntax.)  The regular
   expression can include a single capture, or parenthesized subexpression,
   which can then be referenced in the <replaceable>database-username</replaceable>
   field as <literal>\1</literal> (backslash-one).  This allows the mapping of
   multiple user names in a single line, which is particularly useful for
   simple syntax substitutions.  For example, these entries
<programlisting>
mymap   /^(.*)@mydomain\.com$      \1
mymap   /^(.*)@otherdomain\.com$   guest
</programlisting>
   will remove the domain part for users with system user names that end with
   <literal>@mydomain.com</literal>, and allow any user whose system name ends with
   <literal>@otherdomain.com</literal> to log in as <literal>guest</literal>.
   Quoting a <replaceable>database-username</replaceable> containing
   <literal>\1</literal> <emphasis>does not</emphasis> make
   <literal>\1</literal> lose its special meaning.
  </para>
  <para>
   If the <replaceable>database-username</replaceable> field starts with
   a slash (<literal>/</literal>), the remainder of the field is treated
   as a regular expression (see <xref linkend="posix-syntax-details"/>
   for details of <productname>PostgreSQL</productname>'s regular
   expression syntax). It is not possible to use <literal>\1</literal>
   to use a capture from regular expression on
   <replaceable>system-username</replaceable> for a regular expression
   on <replaceable>database-username</replaceable>.
  </para>

  <tip>
   <para>
    Keep in mind that by default, a regular expression can match just part of
    a string.  It's usually wise to use <literal>^</literal> and <literal>$</literal>, as
    shown in the above example, to force the match to be to the entire
    system user name.
   </para>
  </tip>

  <para>
   A <filename>pg_ident.conf</filename> file that could be used in
   conjunction with the <filename>pg_hba.conf</filename> file in <xref
   linkend="example-pg-hba.conf"/> is shown in <xref
   linkend="example-pg-ident.conf"/>. In this example, anyone
   logged in to a machine on the 192.168 network that does not have the
   operating system user name <literal>bryanh</literal>, <literal>ann</literal>, or
   <literal>robert</literal> would not be granted access. Unix user
   <literal>robert</literal> would only be allowed access when he tries to
   connect as <productname>PostgreSQL</productname> user <literal>bob</literal>, not
   as <literal>robert</literal> or anyone else. <literal>ann</literal> would
   only be allowed to connect as <literal>ann</literal>. User
   <literal>bryanh</literal> would be allowed to connect as either
   <literal>bryanh</literal> or as <literal>guest1</literal>.
  </para>

  <example id="example-pg-ident.conf">
   <title>An Example <filename>pg_ident.conf</filename> File</title>
<programlisting>
# MAPNAME       SYSTEM-USERNAME         PG-USERNAME

omicron         bryanh                  bryanh
omicron         ann                     ann
# bob has user name robert on these machines
omicron         robert                  bob
# bryanh can also connect as guest1
omicron         bryanh                  guest1
</programlisting>
  </example>
 </sect1>

 <sect1 id="auth-methods">
  <title>Authentication Methods</title>

  <para>
   <productname>PostgreSQL</productname> provides various methods for
   authenticating users:

   <itemizedlist>
    <listitem>
     <para>
      <link linkend="auth-trust">Trust authentication</link>, which
      simply trusts that users are who they say they are.