Re: Patch: add conversion from pg_wchar to multibyte
От | Tatsuo Ishii |
---|---|
Тема | Re: Patch: add conversion from pg_wchar to multibyte |
Дата | |
Msg-id | 20120711.142326.875632511077408958.t-ishii@sraoss.co.jp обсуждение исходный текст |
Ответ на | Re: Patch: add conversion from pg_wchar to multibyte (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
> Well, when the preceding comment block contains five references to > xemacs and the link for more information leads to www.xemacs.org, > I don't think it's real helpful to add one sentence saying "oh > by the way we're not actually following xemacs". > > I continue to think that we'd be better off to follow the xemacs > spec, as the subdivisions the emacs spec is insisting on seem like > entirely useless complication. The only possible reason for doing > it the emacs way is that it would provide room for twice as many > charset IDs ... but the present design for wchar conversion destroys > that advantage, because it requires the charset ID spaces to be > nonoverlapping anyhow. Moreover, it's not apparent to me that > charset standards are still proliferating, so I doubt that we need > any more ID space. Well, we have been following emacs spec, not xemacs spec from the day 0. I don't see any value to switch to xemacs way at this moment, because I think the reason why we support particular encoding is, to keep on supporting existing user data, not "enhance" our internal architecture. If you like xeamcs's spec, I think you'd better add new encoding, rather than break data compatibility. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp
В списке pgsql-hackers по дате отправления: