MIME-Version: 1.0
From: Zhongpu Chen <chenloveit@gmail.com>
Date: Sat, 2 May 2026 10:31:12 +0800
Message-ID: 
 <CA+1gyqJJJDhq=cc_D0ad59WH_OD2G_mN54xTru0KYoNaLkF48Q@mail.gmail.com>
Subject: Proposal: tighten validation for legacy EUC encodings or document
 that accepted byte sequences may be unconvertible to UTF8
To: pgsql-hackers@lists.postgresql.org
Content-Type: multipart/alternative; boundary="0000000000005c9f0d0650cc7ee0"
Archived-At: 
 <https://www.postgresql.org/message-id/CA%2B1gyqJJJDhq%3Dcc_D0ad59WH_OD2G_mN54xTru0KYoNaLkF48Q%40mail.gmail.com>
Precedence: bulk

--0000000000005c9f0d0650cc7ee0
Content-Type: text/plain; charset="UTF-8"

See the related bug report
https://www.postgresql.org/message-id/CA%2B1gyqL7uiQhfLcYWpHNUKQgHjQc7sOPthSTiaxLDZzcrGFYSg%40mail.gmail.com

Currently PostgreSQL accepts structurally well-formed EUC_CN byte sequences
such as 0xA2A3 into text columns. The value round-trips when
client_encoding is EUC_CN, but fails when client_encoding is UTF8 because
euc_cn_to_utf8 has no mapping.

If this behavior is intentional for compatibility, the documentation should
explicitly say that validation for some legacy encodings is byte-structure
validation, not mapping-table validation.
If it is not intentional, stricter validation could reject unassigned byte
positions at input time.

-- 
Zhongpu Chen

--0000000000005c9f0d0650cc7ee0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>See the related bug report=C2=A0<a href=3D"https://ww=
w.postgresql.org/message-id/CA%2B1gyqL7uiQhfLcYWpHNUKQgHjQc7sOPthSTiaxLDZzc=
rGFYSg%40mail.gmail.com">https://www.postgresql.org/message-id/CA%2B1gyqL7u=
iQhfLcYWpHNUKQgHjQc7sOPthSTiaxLDZzcrGFYSg%40mail.gmail.com</a></div><div><b=
r></div><div>Currently PostgreSQL accepts structurally well-formed EUC_CN b=
yte sequences such as 0xA2A3 into text columns. The value round-trips when =
client_encoding is EUC_CN, but fails when client_encoding is UTF8 because e=
uc_cn_to_utf8 has no mapping.<br><br></div><div>If this behavior is intenti=
onal for compatibility, the documentation should explicitly say that valida=
tion for some legacy encodings is byte-structure validation, not mapping-ta=
ble validation.<br>If it is not intentional, stricter validation could reje=
ct unassigned byte positions at input time.</div><br><span class=3D"gmail_s=
ignature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature" d=
ata-smartmail=3D"gmail_signature"><div dir=3D"ltr">Zhongpu Chen</div></div>=
</div>

--0000000000005c9f0d0650cc7ee0--