aboutsummaryrefslogtreecommitdiff
path: root/doc/src
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2019-07-05 14:17:27 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2019-07-05 14:17:27 -0400
commit0ab1a2e39b6f65b0f6a5879605ddbf12f9f50de4 (patch)
tree5aa82c5c13706d9df7faf787d7c8071478e33dac /doc/src
parentef777cb093e8cb45dd3ae9d3f1499c765147c1dd (diff)
downloadpostgresql-0ab1a2e39b6f65b0f6a5879605ddbf12f9f50de4.tar.gz
postgresql-0ab1a2e39b6f65b0f6a5879605ddbf12f9f50de4.zip
Remove dead encoding-conversion functions.
The code for conversions SQL_ASCII <-> MULE_INTERNAL and SQL_ASCII <-> UTF8 was unreachable, because we long ago changed the wrapper functions pg_do_encoding_conversion() et al so that they have hard-wired behaviors for conversions involving SQL_ASCII. (At least some of those fast paths date back to 2002, though it looks like we may not have been totally consistent about this until later.) Given the lack of complaints, nobody is dissatisfied with this state of affairs. Hence, let's just remove the unreachable code. Also, change CREATE CONVERSION so that it rejects attempts to define such conversions. Since we consider that SQL_ASCII represents lack of knowledge about the encoding in use, such a conversion would be semantically dubious even if it were reachable. Adjust a couple of regression test cases that had randomly decided to rely on these conversion functions rather than any other ones. Discussion: https://postgr.es/m/41163.1559156593@sss.pgh.pa.us
Diffstat (limited to 'doc/src')
-rw-r--r--doc/src/sgml/charset.sgml6
-rw-r--r--doc/src/sgml/func.sgml24
-rw-r--r--doc/src/sgml/ref/create_conversion.sgml22
3 files changed, 21 insertions, 31 deletions
diff --git a/doc/src/sgml/charset.sgml b/doc/src/sgml/charset.sgml
index a2a46c6ab3a..29fe33a9539 100644
--- a/doc/src/sgml/charset.sgml
+++ b/doc/src/sgml/charset.sgml
@@ -1896,7 +1896,11 @@ RESET client_encoding;
<para>
If the client character set is defined as <literal>SQL_ASCII</literal>,
encoding conversion is disabled, regardless of the server's character
- set. Just as for the server, use of <literal>SQL_ASCII</literal> is unwise
+ 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>
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 47cefd8020f..eeb3c46316a 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -2497,18 +2497,6 @@
<tbody>
<row>
- <entry><literal>ascii_to_mic</literal></entry>
- <entry><literal>SQL_ASCII</literal></entry>
- <entry><literal>MULE_INTERNAL</literal></entry>
- </row>
-
- <row>
- <entry><literal>ascii_to_utf8</literal></entry>
- <entry><literal>SQL_ASCII</literal></entry>
- <entry><literal>UTF8</literal></entry>
- </row>
-
- <row>
<entry><literal>big5_to_euc_tw</literal></entry>
<entry><literal>BIG5</literal></entry>
<entry><literal>EUC_TW</literal></entry>
@@ -2779,12 +2767,6 @@
</row>
<row>
- <entry><literal>mic_to_ascii</literal></entry>
- <entry><literal>MULE_INTERNAL</literal></entry>
- <entry><literal>SQL_ASCII</literal></entry>
- </row>
-
- <row>
<entry><literal>mic_to_big5</literal></entry>
<entry><literal>MULE_INTERNAL</literal></entry>
<entry><literal>BIG5</literal></entry>
@@ -2905,12 +2887,6 @@
</row>
<row>
- <entry><literal>utf8_to_ascii</literal></entry>
- <entry><literal>UTF8</literal></entry>
- <entry><literal>SQL_ASCII</literal></entry>
- </row>
-
- <row>
<entry><literal>utf8_to_big5</literal></entry>
<entry><literal>UTF8</literal></entry>
<entry><literal>BIG5</literal></entry>
diff --git a/doc/src/sgml/ref/create_conversion.sgml b/doc/src/sgml/ref/create_conversion.sgml
index 4ddbcfacef2..67b4bd26bed 100644
--- a/doc/src/sgml/ref/create_conversion.sgml
+++ b/doc/src/sgml/ref/create_conversion.sgml
@@ -28,12 +28,15 @@ CREATE [ DEFAULT ] CONVERSION <replaceable>name</replaceable>
<para>
<command>CREATE CONVERSION</command> defines a new conversion between
- character set encodings. Also, conversions that
- are marked <literal>DEFAULT</literal> can be used for automatic encoding
- conversion between
- client and server. For this purpose, two conversions, from encoding A to
- B <emphasis>and</emphasis> from encoding B to A, must be defined.
- </para>
+ two character set encodings.
+ </para>
+
+ <para>
+ Conversions that are marked <literal>DEFAULT</literal> can be used for
+ automatic encoding conversion between client and server. To support that
+ usage, two conversions, from encoding A to B <emphasis>and</emphasis>
+ from encoding B to A, must be defined.
+ </para>
<para>
To be able to create a conversion, you must have <literal>EXECUTE</literal> privilege
@@ -123,6 +126,13 @@ conv_proc(
<title>Notes</title>
<para>
+ Neither the source nor the destination encoding can
+ be <literal>SQL_ASCII</literal>, as the server's behavior for cases
+ involving the <literal>SQL_ASCII</literal> <quote>encoding</quote> is
+ hard-wired.
+ </para>
+
+ <para>
Use <command>DROP CONVERSION</command> to remove user-defined conversions.
</para>