| From: | Henson Choi <assam258(at)gmail(dot)com> |
|---|---|
| To: | SungJun Jang <sjjang112233(at)gmail(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Junwang Zhao <zhjwpku(at)gmail(dot)com>, jian he <jian(dot)universality(at)gmail(dot)com>, li(dot)evan(dot)chao(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org, Tatsuo Ishii <ishii(at)postgresql(dot)org>, thomas(dot)munro(at)gmail(dot)com |
| Subject: | Re: Remove invalid SS2/SS3 handling from EUC-KR routines |
| Date: | 2026-08-20 05:10:38 |
| Message-ID: | CAAAe_zAD0a==rtYZopWZ5WMFjaEzKwaGUmXXGMdFx8KhxBb=dQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi SungJun,
Apologies for the long silence. You asked a direct question in May and
I never answered it; three months went by.
From your message of May 13:
> Does this structure work for you, or would you prefer a different
> approach?
It works. 0001 baseline capture, then 0002 with the fix, is a good
idea.
> Thanks for the clarification.. v3 attached: release-19.sgml hunk
> removed. The commit message now carries the user-visible change:
>
> "The only user-visible effect is that pg_encoding_max_length('EUC_KR')
> now returns 2 instead of 3."
>
> The charset.sgml Table 23.3 fix is retained.
That is what I had asked for. I have now reviewed v3 and I think it
should go in as it stands. CI is green, so I am marking this Ready for
Committer.
This is one of three Korean encoding verifier fixes, each disagreeing
with its own standard in a different direction: this one drops branches
for something that never existed, CP949 (CF 6913) narrows a verifier
that accepts undefined bytes, and JOHAB (BUG #19354) fixes one that
rejects valid ones.
https://commitfest.postgresql.org/patch/6913/
https://postgr.es/m/CAAAe_zCLVunjt1u%2B2E86shwc3hk1x4bzUyU86nY1fq-nAVYN0Q%40mail.gmail.com
Best regards,
Henson
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Henson Choi | 2026-08-20 05:10:43 | Re: Tighten pg_uhc_verifychar() to enforce CP949 lead/trail byte ranges |
| Previous Message | Tom Lane | 2026-08-20 04:43:43 | Re: Test tidscan,sql is not immune to autovacuum in v14 |