Re: Tighten pg_uhc_verifychar() to enforce CP949 lead/trail byte ranges

Hi DoGeon,

Sorry to have kept v2 waiting since July -- the delay is mine.

> Both produce identical output before and after 0002, so they sit in
> the baseline (0001), and 0002's expected diff is still exactly the
> eight message-format changes. Full regression passes.

Confirmed on v2. Both new cases have the same expected output before
and after 0002, so they do sit in 0001, and 0002's diff is still
exactly those eight lines.

The bounds are all pinned now. Each of the eight in the new code has
an accepting case one step inside it and a rejecting case one step
outside, so a bound that drifts either way fails the suite.

The new accept set is also a strict subset of the old one -- nothing
is newly accepted; the change only narrows.

This looks good to me as it stands, so I am marking it Ready for
Committer.

This is one of three Korean encoding verifier fixes, each disagreeing
with its own standard in a different direction: this one narrows a
verifier that accepts undefined bytes, EUC_KR (CF 6761) drops branches
for something that never existed, and JOHAB (BUG #19354) fixes one
that rejects valid ones.

https://commitfest.postgresql.org/patch/6761/

https://postgr.es/m/CAAAe_zCLVunjt1u%2B2E86shwc3hk1x4bzUyU86nY1fq-nAVYN0Q%40mail.gmail.com

Best regards,
Henson