</important>
   </sect2>

   <sect2 id="multibyte-automatic-conversion">
    <title>Automatic Character Set Conversion Between Server and Client</title>

    <para>
     <productname>PostgreSQL</productname> supports automatic character
     set conversion between server and client for many combinations of
     character sets (<xref linkend="multibyte-conversions-supported"/>
     shows which ones).
    </para>

    <para>
     To enable automatic character set conversion, you have to
     tell <productname>PostgreSQL</productname> the character set
     (encoding) you would like to use in the client. There are several
     ways to accomplish this:

     <itemizedlist>
      <listitem>
       <para>
        Using the <command>\encoding</command> command in
        <application>psql</application>.
        <command>\encoding</command> allows you to change client
        encoding on the fly. For
        example, to change the encoding to <literal>SJIS</literal>, type:

<programlisting>
\encoding SJIS
</programlisting>
       </para>
      </listitem>

      <listitem>
       <para>
        <application>libpq</application> (<xref linkend="libpq-control"/>) has functions to control the client encoding.
       </para>
      </listitem>

      <listitem>
       <para>
        Using <command>SET client_encoding TO</command>.

        Setting the client encoding can be done with this SQL command:

<programlisting>
SET CLIENT_ENCODING TO '<replaceable>value</replaceable>';
</programlisting>

        Also you can use the standard SQL syntax <literal>SET NAMES</literal>
        for this purpose:

<programlisting>
SET NAMES '<replaceable>value</replaceable>';
</programlisting>

        To query the current client encoding:

<programlisting>
SHOW client_encoding;
</programlisting>

        To return to the default encoding:

<programlisting>
RESET client_encoding;
</programlisting>
       </para>
      </listitem>

      <listitem>
       <para>
        Using <envar>PGCLIENTENCODING</envar>. If the environment variable
        <envar>PGCLIENTENCODING</envar> is defined in the client's
        environment, that client encoding is automatically selected
        when a connection to the server is made.  (This can
        subsequently be overridden using any of the other methods
        mentioned above.)
       </para>
      </listitem>

      <listitem>
      <para>
       Using the configuration variable <xref
       linkend="guc-client-encoding"/>. If the
       <varname>client_encoding</varname> variable is set, that client
       encoding is automatically selected when a connection to the
       server is made.  (This can subsequently be overridden using any
       of the other methods mentioned above.)
       </para>
      </listitem>

     </itemizedlist>
    </para>

    <para>
     If the conversion of a particular character is not possible
     &mdash; suppose you chose <literal>EUC_JP</literal> for the
     server and <literal>LATIN1</literal> for the client, and some
     Japanese characters are returned that do not have a representation in
     <literal>LATIN1</literal> &mdash; an error is reported.
    </para>

    <para>
     If the client character set is defined as <literal>SQL_ASCII</literal>,
     encoding conversion is disabled, regardless of the server's character
     set.  (However, if the server's character set is
     not <literal>SQL_ASCII</literal>, the server will still check that
     incoming data is valid for that encoding; so the net effect is as
     though the client character set were the same as the server's.)
     Just as for the server, use of <literal>SQL_ASCII</literal> is unwise
     unless you are working with all-ASCII data.
    </para>
   </sect2>

   <sect2 id="multibyte-conversions-supported">
    <title>Available Character Set Conversions</title>

    <para>
     <productname>PostgreSQL</productname> allows conversion between any
     two character sets for which a conversion function is listed in