Message-ID: <1191A5384BD641C68D288AF210BEFDA8@maumau>
From: "MauMau" <maumau307@gmail.com>
To: "Tom Lane" <tgl@sss.pgh.pa.us>,
	"Robert Haas" <robertmhaas@gmail.com>
Cc: "Boguk,    Maksym" <maksymb@fast.au.fujitsu.com>,
 "Heikki Linnakangas" <hlinnakangas@vmware.com>,
 <pgsql-hackers@postgresql.org>
References: <A756FAD7EDC2E24F8CAB7E2F3B5375E918E2D5B8@FALEX03.au.fjanz.com>
 <522594E8.2050106@vmware.com>
 <A756FAD7EDC2E24F8CAB7E2F3B5375E918F332A6@FALEX03.au.fjanz.com>
 <904.1378304922@sss.pgh.pa.us> <B1A7485194DE4FDAB8FA781AFB570079@maumau>
 <CA+TgmobWv_96dSfSHv2ZJWSXAD=QTiBEKw-LT359sGArYe+AXQ@mail.gmail.com>
 <592.1379524680@sss.pgh.pa.us>
In-Reply-To: <592.1379524680@sss.pgh.pa.us>
Subject: Re: UTF8 national character data type support WIP patch and list of
 open issues.
Date: Thu, 19 Sep 2013 07:46:37 +0900
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-2022-jp";
 reply-type=original
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

From: "Tom Lane" <tgl@sss.pgh.pa.us>
> Another point to keep in mind is that UTF16 is not really any easier
> to deal with than UTF8, unless you write code that fails to support
> characters outside the basic multilingual plane.  Which is a restriction
> I don't believe we'd accept.  But without that restriction, you're still
> forced to deal with variable-width characters; and there's nothing very
> nice about the way that's done in UTF16.  So on the whole I think it
> makes more sense to use UTF8 for this.

I feel so.  I guess why Windows, Java, and Oracle chose UTF-16 is ... it was 
UCS-2 only with BMP when they chose it.  So character handling was easier 
and faster thanks to fixed-width encoding.

Regards
MauMau


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers