never considers any
    non-ASCII characters to belong to any of these classes.)
    In addition to these standard character
    classes, <productname>PostgreSQL</productname> defines
    the <literal>word</literal> character class, which is the same as
    <literal>alnum</literal> plus the underscore (<literal>_</literal>)
    character, and
    the <literal>ascii</literal> character class, which contains exactly
    the 7-bit ASCII set.
   </para>

   <para>
    There are two special cases of bracket expressions:  the bracket
    expressions <literal>[[:&lt;:]]</literal> and
    <literal>[[:&gt;:]]</literal> are constraints,
    matching empty strings at the beginning
    and end of a word respectively.  A word is defined as a sequence
    of word characters that is neither preceded nor followed by word
    characters.  A word character is any character belonging to the
    <literal>word</literal> character class, that is, any letter, digit,
    or underscore.  This is an extension, compatible with but not
    specified by <acronym>POSIX</acronym> 1003.2, and should be used with
    caution in software intended to be portable to other systems.
    The constraint escapes described below are usually preferable; they
    are no more standard, but are easier to type.
   </para>
   </sect3>

   <sect3 id="posix-escape-sequences">
    <title>Regular Expression Escapes</title>

   <para>
    <firstterm>Escapes</firstterm> are special sequences beginning with <literal>\</literal>
    followed by an alphanumeric character. Escapes come in several varieties:
    character entry, class shorthands, constraint escapes, and back references.
    A <literal>\</literal> followed by an alphanumeric character but not constituting
    a valid escape is illegal in AREs.
    In EREs, there are no escapes: outside a bracket expression,
    a <literal>\</literal> followed by an alphanumeric character merely stands for
    that character as an ordinary character, and inside a bracket expression,
    <literal>\</literal> is an ordinary character.
    (The latter is the one actual incompatibility between EREs and AREs.)
   </para>

   <para>
    <firstterm>Character-entry escapes</firstterm> exist to make it easier to specify
    non-printing and other inconvenient characters in REs.  They are
    shown in <xref linkend="posix-character-entry-escapes-table"/>.
   </para>

   <para>
    <firstterm>Class-shorthand escapes</firstterm> provide shorthands for certain
    commonly-used character classes.  They are
    shown in <xref linkend="posix-class-shorthand-escapes-table"/>.
   </para>

   <para>
    A <firstterm>constraint escape</firstterm> is a constraint,
    matching the empty string if specific conditions are met,
    written as an escape.  They are
    shown in <xref linkend="posix-constraint-escapes-table"/>.
   </para>

   <para>
    A <firstterm>back reference</firstterm> (<literal>\</literal><replaceable>n</replaceable>) matches the
    same string matched by the previous parenthesized subexpression specified
    by the number <replaceable>n</replaceable>
    (see <xref linkend="posix-constraint-backref-table"/>).  For example,
    <literal>([bc])\1</literal> matches <literal>bb</literal> or <literal>cc</literal>
    but not <literal>bc</literal> or <literal>cb</literal>.
    The subexpression must entirely precede the back reference in the RE.
    Subexpressions are numbered in the order of their leading parentheses.
    Non-capturing parentheses do not define subexpressions.
    The back reference considers only the string characters matched by the
    referenced subexpression, not any constraints contained in it.  For
    example, <literal>(^\d)\1</literal> will match <literal>22</literal>.
   </para>

   <table id="posix-character-entry-escapes-table">
    <title>Regular Expression Character-Entry Escapes</title>

    <tgroup cols="2">
     <thead>
      <row>
       <entry>Escape</entry>
       <entry>Description</entry>
      </row>