</para>
     </listitem>

     <listitem>
      <para>
       Pattern matching operators (<literal>LIKE</literal>, <literal>SIMILAR TO</literal>,
       and POSIX-style regular expressions); locales affect both case
       insensitive matching and the classification of characters by
       character-class regular expressions
       <indexterm><primary>LIKE</primary><secondary>and locales</secondary></indexterm>
       <indexterm><primary>regular expressions</primary><secondary>and locales</secondary></indexterm>
      </para>
     </listitem>

     <listitem>
      <para>
       The <function>to_char</function> family of functions
       <indexterm><primary>to_char</primary><secondary>and locales</secondary></indexterm>
      </para>
     </listitem>

     <listitem>
      <para>
       The ability to use indexes with <literal>LIKE</literal> clauses
      </para>
     </listitem>
    </itemizedlist>
   </para>

   <para>
    The drawback of using locales other than <literal>C</literal> or
    <literal>POSIX</literal> in <productname>PostgreSQL</productname> is its performance
    impact. It slows character handling and prevents ordinary indexes
    from being used by <literal>LIKE</literal>. For this reason use locales
    only if you actually need them.
   </para>

   <para>
    As a workaround to allow <productname>PostgreSQL</productname> to use indexes
    with <literal>LIKE</literal> clauses under a non-C locale, several custom
    operator classes exist. These allow the creation of an index that
    performs a strict character-by-character comparison, ignoring
    locale comparison rules. Refer to <xref linkend="indexes-opclass"/>
    for more information.  Another approach is to create indexes using
    the <literal>C</literal> collation, as discussed in
    <xref linkend="collation"/>.
   </para>
  </sect2>

  <sect2 id="locale-selecting-locales">
   <title>Selecting Locales</title>

   <para>
    Locales can be selected in different scopes depending on requirements.
    The above overview showed how locales are specified using
    <command>initdb</command> to set the defaults for the entire cluster.  The
    following list shows where locales can be selected.  Each item provides
    the defaults for the subsequent items, and each lower item allows
    overriding the defaults on a finer granularity.
   </para>

   <orderedlist>
    <listitem>
     <para>
      As explained above, the environment of the operating system provides the
      defaults for the locales of a newly initialized database cluster.  In
      many cases, this is enough: if the operating system is configured for
      the desired language/territory, by default
      <productname>PostgreSQL</productname> will also behave according
      to that locale.
     </para>
    </listitem>

    <listitem>
     <para>
      As shown above, command-line options for <command>initdb</command>
      specify the locale settings for a newly initialized database cluster.
      Use this if the operating system does not have the locale configuration
      you want for your database system.
     </para>
    </listitem>

    <listitem>
     <para>
      A locale can be selected separately for each database.  The SQL command
      <command>CREATE DATABASE</command> and its command-line equivalent
      <command>createdb</command> have options for that.  Use this for example
      if a database cluster houses databases for multiple tenants with
      different requirements.
     </para>
    </listitem>

    <listitem>
     <para>
      Locale settings can be made for individual table columns.  This uses an
      SQL object called <firstterm>collation</firstterm> and is explained in
      <xref linkend="collation"/>.  Use this for example to sort data in
      different languages or customize the sort order of a particular table.
     </para>
    </listitem>

    <listitem>
     <para>
      Finally, locales can be selected for an individual query.  Again, this
      uses SQL