Re: INFORMATION_SCHEMA note

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

In response to

Responses

Browse pgsql-hackers by date

  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