Robert Haas <robertmhaas@gmail.com> writes:
> In the reverse transformation implemented by pg_wchar2mule_with_len,
> if the byte stored with shift 16 IS_LC1 or IS_LC2, then we decode 2 or
> 3 bytes, respectively, exactly as I would expect. ASCII decoding is
> also as I would expect. The case I don't understand is what happens
> when the leading byte of the multibyte character was IS_LCPRV1 or
> IS_LCPRV2.
Some inspection of pg_wchar.h suggests that the IS_LCPRV1 and IS_LCPRV2
cases are unused: the file doesn't define any encoding labels that match
the byte values they accept, nor do the comments suggest that Emacs has
any such labels either. If true, it would not be much of a stretch to
believe that any code claiming to support these cases could be broken.
regards, tom lane
