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
Subject: Re: BUG #19354: JOHAB rejects valid byte sequences
In-reply-to: <CA+hUKGJMrcS=hBkqVk=5pjM4w8edG=_ArASC82RqB6HQro-v-g@mail.gmail.com>
References: <19354-eefe6d8b3e84f9f2@postgresql.org> <CA+TgmoaRGSezRaA7x00X495Qho8WGTzggbDSUt-JsruXceZWug@mail.gmail.com> <CA+zULE4L4rA2DLAcfy=eQL7w_ZexV4P5zpQRbP=_qrhJBEOzjg@mail.gmail.com> <2292889.1765846569@sss.pgh.pa.us> <CAE2r8H5vaSyaC_t1FcpHBo-BB_=SrFj7GFnOC-SxC6WDf5c9VA@mail.gmail.com> <CA+zULE47EXZOp7qKYODd+mjSgDiR-WX5ZNBkwdKnj-Zc0FT58w@mail.gmail.com> <CA+TgmoZaoc37ohnhF5inoPxWzfoznV483xQw8Fmw+ELFScv47g@mail.gmail.com> <2393116.1765899706@sss.pgh.pa.us> <CA+TgmoaoW4F2rRzYcQQim9ddT4-6H3oi0UYV9Ucw-rRQ5MdHsg@mail.gmail.com> <CA+hUKGKy-ViGBXdOjcPownBM=OdWiULO8H1RyH1r_8qNp=U4CA@mail.gmail.com> <6a8122ac-123d-4e93-9269-0b3be1e4a5a4@iki.fi> <CAAAe_zCLVunjt1u+2E86shwc3hk1x4bzUyU86nY1fq-nAVYN0Q@mail.gmail.com> <CA+hUKGJMrcS=hBkqVk=5pjM4w8edG=_ArASC82RqB6HQro-v-g@mail.gmail.com>
Comments: In-reply-to Thomas Munro <thomas.munro@gmail.com>
	message dated "Wed, 15 Apr 2026 13:49:24 +1200"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <1910468.1776218778.1@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit
Date: Tue, 14 Apr 2026 22:06:18 -0400
Message-ID: <1910469.1776218778@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/1910469.1776218778%40sss.pgh.pa.us>
Precedence: bulk

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