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