My unit tests uncovered the fact that PostgreSQL's support for JOHAB had been incomplete (or worse) for a long time, and the prospects seemed poor. There were competing standards, in a wild landscape of sometimes very rare Korean encodings, and the implementation was incomplete.
(This wasn't as serious as it may sound, in that PostgreSQL supports JOHAB as a client encoding only. This means that it never used this encoding for storing data in a database — it was only for transient use in communication with the client.)
So it was resolved to remove JOHAB support from PostgreSQL immediately. Great news for me: I could simply delete the code, and the enum entry. It made the libpqxx 8.0 release a little easier. There are even security concerns: the various layers of software need to agree on whether a byte that looks like an ASCII quote or a backslash is actually a quote or a backslash, or merely a byte of the same value embedded in a multi-byte character. This is the stuff of SQL injections.
But then some intrepid developers looked into the details and they found that actually, the situation was salvageable. And they went and salvaged it.
So now it looks like we'll need libpqxx support for this encoding back. But the test that originally tripped up the problem still won't pass, so we may have to run it conditionally, if the postgres server and libpq are recent enough.
My unit tests uncovered the fact that PostgreSQL's support for JOHAB had been incomplete (or worse) for a long time, and the prospects seemed poor. There were competing standards, in a wild landscape of sometimes very rare Korean encodings, and the implementation was incomplete.
(This wasn't as serious as it may sound, in that PostgreSQL supports JOHAB as a client encoding only. This means that it never used this encoding for storing data in a database — it was only for transient use in communication with the client.)
So it was resolved to remove JOHAB support from PostgreSQL immediately. Great news for me: I could simply delete the code, and the
enumentry. It made the libpqxx 8.0 release a little easier. There are even security concerns: the various layers of software need to agree on whether a byte that looks like an ASCII quote or a backslash is actually a quote or a backslash, or merely a byte of the same value embedded in a multi-byte character. This is the stuff of SQL injections.But then some intrepid developers looked into the details and they found that actually, the situation was salvageable. And they went and salvaged it.
So now it looks like we'll need libpqxx support for this encoding back. But the test that originally tripped up the problem still won't pass, so we may have to run it conditionally, if the postgres server and libpq are recent enough.