I wrote: > Tatsuo Ishii <is...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
