LIKE 'f_o' COLLATE ign_punct</literal> is true because one can partition
    <literal>.foo.</literal> into <literal>.f, o, o.</literal>, and then
    <literal>'.f' = 'f' COLLATE ign_punct</literal>, <literal>'o'</literal>
    matches the <literal>_</literal> wildcard, and <literal>'o.' = 'o' COLLATE
    ign_punct</literal>.  But <literal>'.foo.' LIKE '_oo' COLLATE
    ign_punct</literal> is false because <literal>.foo.</literal> cannot be
    partitioned in a way that the first character is any character and the
    rest of the string compares equal to <literal>oo</literal>.  (Note that
    the single-character wildcard always matches exactly one character,
    independent of the collation.  So in this example, the
    <literal>_</literal> would match <literal>.</literal>, but then the rest
    of the input string won't match the rest of the pattern.)
   </para>

   <para>
    <function>LIKE</function> pattern matching always covers the entire
    string.  Therefore, if it's desired to match a sequence anywhere within
    a string, the pattern must start and end with a percent sign.
   </para>

   <para>
    To match a literal underscore or percent sign without matching
    other characters, the respective character in
    <replaceable>pattern</replaceable> must be
    preceded by the escape character.  The default escape
    character is the backslash but a different one can be selected by
    using the <literal>ESCAPE</literal> clause.  To match the escape
    character itself, write two escape characters.
   </para>

   <note>
    <para>
     If you have <xref linkend="guc-standard-conforming-strings"/> turned off,
     any backslashes you write in literal string constants will need to be
     doubled.  See <xref linkend="sql-syntax-strings"/> for more information.
    </para>
   </note>

   <para>
    It's also possible to select no escape character by writing
    <literal>ESCAPE ''</literal>.  This effectively disables the
    escape mechanism, which makes it impossible to turn off the
    special meaning of underscore and percent signs in the pattern.
   </para>

   <para>
    According to the SQL standard, omitting <literal>ESCAPE</literal>
    means there is no escape character (rather than defaulting to a
    backslash), and a zero-length <literal>ESCAPE</literal> value is
    disallowed.  <productname>PostgreSQL</productname>'s behavior in
    this regard is therefore slightly nonstandard.
   </para>

   <para>
    The key word <token>ILIKE</token> can be used instead of
    <token>LIKE</token> to make the match case-insensitive according to the
    active locale.  (But this does not support nondeterministic collations.)
    This is not in the <acronym>SQL</acronym> standard but is a
    <productname>PostgreSQL</productname> extension.
   </para>

   <para>
    The operator <literal>~~</literal> is equivalent to
    <function>LIKE</function>, and <literal>~~*</literal> corresponds to
    <function>ILIKE</function>.  There are also
    <literal>!~~</literal> and <literal>!~~*</literal> operators that
    represent <function>NOT LIKE</function> and <function>NOT
    ILIKE</function>, respectively.  All of these operators are
    <productname>PostgreSQL</productname>-specific.  You may see these
    operator names in <command>EXPLAIN</command> output and similar
    places, since the parser actually translates <function>LIKE</function>
    et al. to these operators.
   </para>

   <para>
    The phrases <function>LIKE</function>, <function>ILIKE</function>,
    <function>NOT LIKE</function>, and <function>NOT ILIKE</function> are
    generally treated as operators
    in <productname>PostgreSQL</productname> syntax; for example they can
    be used in <replaceable>expression</replaceable>
    <replaceable>operator</replaceable> ANY
    (<replaceable>subquery</replaceable>) constructs, although
    an <literal>ESCAPE</literal> clause cannot be included there.  In some
    obscure cases it may be necessary to use the underlying