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 collation objects.  This could be used to change the sort order
      based on run-time choices or for ad-hoc experimentation.
     </para>
    </listitem>
   </orderedlist>
  </sect2>

  <sect2 id="locale-providers">
   <title>Locale Providers</title>

   <para>
    A locale provider specifies which library defines the locale behavior for
    collations and character classifications.
   </para>

   <para>
    The commands and tools that select the locale settings, as described
    above, each have an option to select the locale provider. Here is an
    example to initialize a database cluster using the ICU provider:
<programlisting>
initdb --locale-provider=icu --icu-locale=en
</programlisting>
    See the description of the respective commands and programs for
    details.  Note that you can mix locale providers at different
    granularities, for example use <literal>libc</literal> by default for the
    cluster but have one database that uses the <literal>icu</literal>
    provider, and then have collation objects using either provider within
    those databases.
   </para>

   <para>
    Regardless of the locale provider, the operating system is still used to
    provide some locale-aware behavior, such as messages (see <xref
    linkend="guc-lc-messages"/>).
   </para>

   <para>
    The available locale providers are listed below:
   </para>

   <variablelist>
    <varlistentry>
     <term><literal>builtin</literal></term>
     <listitem>
      <para>
       The <literal>builtin</literal> provider uses built-in operations. Only
       the <literal>C</literal>, <literal>C.UTF-8</literal>, and
       <literal>PG_UNICODE_FAST</literal> locales are supported for this
       provider.
      </para>
      <para>
       The <literal>C</literal> locale behavior is identical to the
       <literal>C</literal> locale in the libc provider. When using this
       locale, the behavior may depend on the database encoding.
      </para>
      <para>
       The <literal>C.UTF-8</literal> locale is available only for when the
       database encoding is <literal>UTF-8</literal>, and the behavior is
       based on Unicode. The collation uses the code point values only. The
       regular expression character classes are based on the "POSIX
       Compatible" semantics, and the case mapping is the "simple" variant.
      </para>
      <para>
       The <literal>PG_UNICODE_FAST</literal> locale is available only when
       the database encoding is <literal>UTF-8</literal>, and the behavior is
       based on Unicode. The collation uses the code point values only. The
       regular expression character classes are based on the "Standard"
       semantics, and the case mapping is the "full" variant.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><literal>icu</literal></term>
     <listitem>
      <para>
       The <literal>icu</literal> provider uses the external
       ICU<indexterm><primary>ICU</primary></indexterm>