I wrote:
> Tatsuo Ishii <ishii@postgresql.org> writes:
>>> I have added comments about mule internal encoding by refreshing my
>>> memory and from old document found on
>>> web(http://mibai.tec.u-ryukyu.ac.jp/cgi-bin/info2www?%28mule%29Buffer%20and%20string).
>> Any objection to apply my patch?
> It needs a bit of copy-editing, and I think we need to do more than just
> add comments: the various byte values should have #defines so that you
> can grep for code usages. I'll see what I can do with it.
I cleaned up the comments in pg_wchar.h some more, added #define
symbols for the LCPRVn marker codes, and committed it.
So far as I can see, the only LCPRVn marker code that is actually in
use right now is 0x9d --- there are no instances of 9a, 9b, or 9c
that I can find.
I also read in the xemacs internals doc, at
http://www.xemacs.org/Documentation/21.5/html/internals_26.html#SEC145
that XEmacs thinks the marker code for private single-byte charsets
is 0x9e (only) and that for private multi-byte charsets is 0x9f (only);
moreover they think 0x9a-0x9d are potential future official multibyte
charset codes. I don't know how we got to the current state of using
0x9a-0x9d as private charset markers, but it seems pretty inconsistent
with XEmacs.
Since only 0x9d could possibly be on-disk anywhere at the moment (unless
I'm missing something), I think we would be well advised to redefine our
marker codes thus:
LCPRV1 0x9e (only) (matches XEmacs spec)LCPRV2 0x9d (only) (doesn't match XEmacs, but too late to change)
This would simplify and speed up the IS_LCPRVn macros, simplify the
conversions that Alexander is worried about, and get us out from under
the risk that XEmacs will assign their next three official multibyte
encoding IDs. We're still in trouble if they ever get to 0x9d, but
since that's the last code they have, I bet they will be in no hurry
to use it up.
regards, tom lane