diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2019-07-05 14:17:27 -0400 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2019-07-05 14:17:27 -0400 |
commit | 0ab1a2e39b6f65b0f6a5879605ddbf12f9f50de4 (patch) | |
tree | 5aa82c5c13706d9df7faf787d7c8071478e33dac /doc/src | |
parent | ef777cb093e8cb45dd3ae9d3f1499c765147c1dd (diff) | |
download | postgresql-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.sgml | 6 | ||||
-rw-r--r-- | doc/src/sgml/func.sgml | 24 | ||||
-rw-r--r-- | doc/src/sgml/ref/create_conversion.sgml | 22 |
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> |