Given the lack of a clear spec,the existence of multiple JOHAB variants,and how long this has apparently been "working" without anyone noticing,IMHO desupporting it does seem like the least risky option.At this point,trying to fix JOHAB variants feels like opening a pretty big can of worms,especially with the potential for dump/reload surprises or subtle parsing/security issues.
I don't have additional data to add,but +1 on removal or deprecation being a reasonable outcome here,given how obscure and effectively dead the encoding is nowadays.
Thanks for digging into this.
Cheers, Vasuki M
On Tue, Dec 16, 2025 at 11:46 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Jeroen Vermeulen <jtvjtv@gmail.com> writes: > This bit worries me: "TlOther, vendor-defined, Johab variants also exist" — > such as an EBCDIC-based one and a stateful one!
Yeah. So what we have here is:
1. Our JOHAB implementation has apparently been wrong since day one.
2. Wrongness may be in the eye of the beholder, since there are multiple versions of JOHAB.
3. Your complaint is the first, AFAIR.
4. That wikipedia page says "Following the introduction of Unified Hangul Code by Microsoft in Windows 95, and Hangul Word Processor abandoning Johab in favour of Unicode in 2000, Johab ceased to be commonly used."
Given these things, I wonder if we shouldn't desupport JOHAB rather than attempt to fix it. Fixing would likely be a significant amount of work: if we don't even have the character lengths right, how likely is it that our conversions to other character sets are correct? I also worry that if different PG versions have different ideas of the mapping, there could be room for dump/reload problems, and maybe even security problems related to the backslash issue.
