Re: Patch: add conversion from pg_wchar to multibyte

From: Tatsuo Ishii <ishii(at)postgresql(dot)org>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: ishii(at)postgresql(dot)org, robertmhaas(at)gmail(dot)com, aekorotkov(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Patch: add conversion from pg_wchar to multibyte
Date: 2012-07-11 05:23:26
Message-ID: 20120711.142326.875632511077408958.t-ishii@sraoss.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joel Jacobson 2012-07-11 08:17:31 Re: Schema version management
Previous Message Daniel Farina 2012-07-11 05:22:27 Re: DELETE vs TRUNCATE explanation