Re: Patch: add conversion from pg_wchar to multibyte
От | Tatsuo Ishii |
---|---|
Тема | Re: Patch: add conversion from pg_wchar to multibyte |
Дата | |
Msg-id | 20120706.095202.1949717139594072856.t-ishii@sraoss.co.jp обсуждение исходный текст |
Ответ на | Re: Patch: add conversion from pg_wchar to multibyte (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Patch: add conversion from pg_wchar to multibyte
|
Список | pgsql-hackers |
> 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
В списке pgsql-hackers по дате отправления: