From: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: INFORMATION_SCHEMA note |
Date: | 2024-01-04 12:39:46 |
Message-ID: | 20240104.213946.594640159461314615.t-ishii@sranhm.sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
(typo in the subject fixed)
> In the following paragraph in information_schema:
>
> <term>character encoding form</term>
> <listitem>
> <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>
> 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
> as an SQL object, but are visible in this view.
>
> This claims that the LATIN1 repertoire only uses one encoding form,
> but actually LATIN1 can be encoded in another form: ISO-2022-JP-2 (a 7
> bit encoding. See RFC 1554
> (https://datatracker.ietf.org/doc/html/rfc1554) for more details).
>
> If we still want to list a use-one-encoding-form example, probably we
> could use LATIN2 instead or others that are not supported by
> ISO-2022-JP-2 (ISO-2022-JP-2 supports LATIN1 and LATIN7).
>
> Attached is the patch that does this.
Any objection?
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
From | Date | Subject | |
---|---|---|---|
Next Message | Michail Nikolaev | 2024-01-04 12:45:06 | Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements |
Previous Message | Ashutosh Bapat | 2024-01-04 12:34:20 | Re: Adding facility for injection points (or probe points?) for more advanced tests |