> Tatsuo Ishii <ishii@postgresql.org> writes:
>>> 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.
>
>> At the time when mule internal code was introduced to PostgreSQL,
>> xemacs did not have multi encoding capabilty and mule (a patch to
>> emacs) was the only implementation allowed to use multi encoding. So I
>> used the specification of mule documented in the URL I wrote.
>
> I see. Given that upstream has decided that a simpler definition is
> more appropriate, is there any reason not to follow their lead, to the
> extent that we can do so without breaking existing on-disk data?
Please let me spend week end to understand the their latest spec.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp