]> git.ipfire.org Git - thirdparty/postgresql.git/commitdiff
Doc: fix character_sets view.
authorTatsuo Ishii <ishii@postgresql.org>
Tue, 9 Jan 2024 10:56:00 +0000 (19:56 +0900)
committerTatsuo Ishii <ishii@postgresql.org>
Tue, 9 Jan 2024 10:56:00 +0000 (19:56 +0900)
The note regarding character encoding form in "The Information Schema"
said that LATIN1 character repertoires only use one encoding form
LATIN1. This is not correct because LATIN1 has another encoding form
ISO-2022-JP-2. To fix this, replace LATIN1 with LATIN2, which is not
supported by ISO-2022-JP-2, thus it can be said that LATIN2 only uses
one encoding form.

Back-patch to supported branches.

Author: Tatsuo Ishii
Reviewed-by: Daniel Gustafsson
Discussion: https://postgr.es/m/flat/20240102.153925.1147403616414525145.t-ishii%40sranhm.sra.co.jp

doc/src/sgml/information_schema.sgml

index 906fe7819f5e58d06929a7d09033afbe8c04598c..4ad294063523eea69e7dfc52c2c5c7bbcad478b0 100644 (file)
       <para>
        An encoding of some character repertoire.  Most older character
        repertoires only use one encoding form, and so there are no
-       separate names for them (e.g., <literal>LATIN1</literal> is an
-       encoding form applicable to the <literal>LATIN1</literal>
+       separate names for them (e.g., <literal>LATIN2</literal> is an
+       encoding form applicable to the <literal>LATIN2</literal>
        repertoire).  But for example Unicode has the encoding forms
        <literal>UTF8</literal>, <literal>UTF16</literal>, etc. (not
        all supported by PostgreSQL).  Encoding forms are not exposed