Re: BUG #19354: JOHAB rejects valid byte sequences
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: assam258@gmail.com, Heikki Linnakangas <hlinnaka@iki.fi>,
Robert Haas <robertmhaas@gmail.com>,
Jeroen Vermeulen <jtvjtv@gmail.com>,
VASUKI M <vasukianand0119@gmail.com>, pgsql-bugs@lists.postgresql.org
Date: 2026-04-15T02:06:18Z
Lists: pgsql-bugs
Thomas Munro <thomas.munro@gmail.com> writes: > On Wed, Apr 15, 2026 at 1:20 PM Henson Choi <assam258@gmail.com> wrote: >> I understand the appeal of simply deleting a dead-looking encoding, >> and Thomas' removal patch is clean work. However, Korean archival >> data from the 1990s (government records, academic repositories, early >> online corpora) does exist as JOHAB bytes; as a client encoding, JOHAB >> in PostgreSQL provides a straightforward ingest path >> (client_encoding=JOHAB, convert_from, then store as UTF-8). Once >> removed, that path closes with no obvious alternative short of >> preprocessing outside PostgreSQL. Fixing the verifier preserves the >> capability at the cost of a ~30-line correction plus tests. > The counter argument would be that you could use iconv > --from-code=JOHAB ..., or libiconv, or the codecs available in Python, > Java, etc for dealing with historical archived data, something that > data archivists must be very aware of. Sure. But it's not comfortable to remove a user-visible feature we've had for decades. My own primary concern about it was that a correct fix could require non-backwards-compatible behavior changes. Henson's analysis says that that's not a problem. So assuming this patch withstands review, I'd be much happier to see it applied than to remove JOHAB. No opinion at the moment about whether to back-patch. regards, tom lane
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix comments for Korean encodings in encnames.c
- e5fb1ff5bed9 14.23 landed
- 78f8fbc8ab5f 15.18 landed
- 5ef61f417f17 16.14 landed
- ec61832231c4 17.10 landed
- ea94d2e6734e 18.4 landed
- 9a618901a476 19 (unreleased) landed
-
Fix the inadvertent libpq ABI breakage discovered by Martin Pitt: the
- 8468146b03c8 8.3.0 cited
-
> Tatsuo Ishii wrote:
- a8bd7e1c6e02 7.3.1 cited