1- <!-- $PostgreSQL: pgsql/doc/src/sgml/charset.sgml,v 2.73 2005/06/21 04:02:29 tgl Exp $ -->
1+ <!-- $PostgreSQL: pgsql/doc/src/sgml/charset.sgml,v 2.74 2005/10/13 21:43:43 tgl Exp $ -->
22
33<chapter id="charset">
44 <title>Localization</>
@@ -517,8 +517,8 @@ initdb --locale=sv_SE
517517 </row>
518518 <row>
519519 <entry><literal>SQL_ASCII</literal></entry>
520- <entry><acronym>ASCII</acronym> </entry>
521- <entry>English </entry>
520+ <entry>unspecified (see text) </entry>
521+ <entry><emphasis>any</> </entry>
522522 <entry>1</entry>
523523 <entry></entry>
524524 </row>
@@ -533,7 +533,7 @@ initdb --locale=sv_SE
533533 <entry><literal>UTF8</literal></entry>
534534 <entry>Unicode, 8-bit</entry>
535535 <entry><emphasis>all</></entry>
536- <entry>1-3 </entry>
536+ <entry>1-4 </entry>
537537 <entry><literal>Unicode</></entry>
538538 </row>
539539 <row>
@@ -595,6 +595,21 @@ initdb --locale=sv_SE
595595 JDBC driver does not support <literal>MULE_INTERNAL</>, <literal>LATIN6</>,
596596 <literal>LATIN8</>, and <literal>LATIN10</>.
597597 </para>
598+
599+ <para>
600+ The <literal>SQL_ASCII</> setting behaves considerably differently
601+ from the other settings. When the server character set is
602+ <literal>SQL_ASCII</>, the server interprets byte values 0-127
603+ according to the ASCII standard, while byte values 128-255 are taken
604+ as uninterpreted characters. No encoding conversion will be done when
605+ the setting is <literal>SQL_ASCII</>. Thus, this setting is not so
606+ much a declaration that a specific encoding is in use, as a declaration
607+ of ignorance about the encoding. In most cases, if you are
608+ working with any non-ASCII data, it is unwise to use the
609+ <literal>SQL_ASCII</> setting, because
610+ <productname>PostgreSQL</productname> will be unable to help you by
611+ converting or validating non-ASCII characters.
612+ </para>
598613 </sect2>
599614
600615 <sect2>
@@ -884,9 +899,7 @@ $ <userinput>psql -l</userinput>
884899 </row>
885900 <row>
886901 <entry><literal>SQL_ASCII</literal></entry>
887- <entry><emphasis>SQL_ASCII</emphasis>,
888- <literal>MULE_INTERNAL</literal>,
889- <literal>UTF8</literal>
902+ <entry><emphasis>any (no conversion will be performed)</emphasis>
890903 </entry>
891904 </row>
892905 <row>
@@ -956,7 +969,7 @@ $ <userinput>psql -l</userinput>
956969 </table>
957970
958971 <para>
959- To enable the automatic character set conversion, you have to
972+ To enable automatic character set conversion, you have to
960973 tell <productname>PostgreSQL</productname> the character set
961974 (encoding) you would like to use in the client. There are several
962975 ways to accomplish this:
@@ -1070,6 +1083,13 @@ RESET client_encoding;
10701083 hexadecimal byte values in parentheses, e.g.,
10711084 <literal>(826C)</literal>.
10721085 </para>
1086+
1087+ <para>
1088+ If the client character set is defined as <literal>SQL_ASCII</>,
1089+ encoding conversion is disabled, regardless of the server's character
1090+ set. Just as for the server, use of <literal>SQL_ASCII</> is unwise
1091+ unless you are working with all-ASCII data.
1092+ </para>
10731093 </sect2>
10741094
10751095 <sect2>
0 commit comments