--lc-collate=ko_KR.euckr --lc-ctype=ko_KR.euckr korean
</screen>

     This will create a database named <literal>korean</literal> that
     uses the character set <literal>EUC_KR</literal>, and locale <literal>ko_KR</literal>.
     Another way to accomplish this is to use this SQL command:

<programlisting>
CREATE DATABASE korean WITH ENCODING 'EUC_KR' LC_COLLATE='ko_KR.euckr' LC_CTYPE='ko_KR.euckr' TEMPLATE=template0;
</programlisting>

     Notice that the above commands specify copying the <literal>template0</literal>
     database.  When copying any other database, the encoding and locale
     settings cannot be changed from those of the source database, because
     that might result in corrupt data.  For more information see
     <xref linkend="manage-ag-templatedbs"/>.
    </para>

    <para>
     The encoding for a database is stored in the system catalog
     <literal>pg_database</literal>.  You can see it by using the
     <command>psql</command> <option>-l</option> option or the
     <command>\l</command> command.

<screen>
$ <userinput>psql -l</userinput>
                                         List of databases
   Name    |  Owner   | Encoding  |  Collation  |    Ctype    |          Access Privileges
-----------+----------+-----------+-------------+-------------+-------------------------------------
 clocaledb | hlinnaka | SQL_ASCII | C           | C           |
 englishdb | hlinnaka | UTF8      | en_GB.UTF8  | en_GB.UTF8  |
 japanese  | hlinnaka | UTF8      | ja_JP.UTF8  | ja_JP.UTF8  |
 korean    | hlinnaka | EUC_KR    | ko_KR.euckr | ko_KR.euckr |
 postgres  | hlinnaka | UTF8      | fi_FI.UTF8  | fi_FI.UTF8  |
 template0 | hlinnaka | UTF8      | fi_FI.UTF8  | fi_FI.UTF8  | {=c/hlinnaka,hlinnaka=CTc/hlinnaka}
 template1 | hlinnaka | UTF8      | fi_FI.UTF8  | fi_FI.UTF8  | {=c/hlinnaka,hlinnaka=CTc/hlinnaka}
(7 rows)
</screen>
    </para>

    <important>
     <para>
      On most modern operating systems, <productname>PostgreSQL</productname>
      can determine which character set is implied by the <envar>LC_CTYPE</envar>
      setting, and it will enforce that only the matching database encoding is
      used.  On older systems it is your responsibility to ensure that you use
      the encoding expected by the locale you have selected.  A mistake in
      this area is likely to lead to strange behavior of locale-dependent
      operations such as sorting.
     </para>

     <para>
      <productname>PostgreSQL</productname> will allow superusers to create
      databases with <literal>SQL_ASCII</literal> encoding even when
      <envar>LC_CTYPE</envar> is not <literal>C</literal> or <literal>POSIX</literal>.  As noted
      above, <literal>SQL_ASCII</literal> does not enforce that the data stored in
      the database has any particular encoding, and so this choice poses risks
      of locale-dependent misbehavior.  Using this combination of settings is
      deprecated and may someday be forbidden altogether.
     </para>
    </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