From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>
cc: "'Tatsuo Ishii'" <ishii@sraoss.co.jp>,
        "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: Supporting SJIS as a database encoding
In-reply-to: <0A3221C70F24FB45833433255569204D1F5E6615@G01JPEXMBYT05>
References: <0A3221C70F24FB45833433255569204D1F5E5F9D@G01JPEXMBYT05>
 <20160905.163854.612818171756520492.t-ishii@sraoss.co.jp>
 <0A3221C70F24FB45833433255569204D1F5E602E@G01JPEXMBYT05>
 <9599.1473086835@sss.pgh.pa.us>
 <0A3221C70F24FB45833433255569204D1F5E6615@G01JPEXMBYT05>
Comments: In-reply-to "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>
	message dated "Tue, 06 Sep 2016 02:51:13 -0000"
Date: Mon, 05 Sep 2016 23:10:14 -0400
Message-ID: <27598.1473131414@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

"Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com> writes:
> Using multibyte-functions like mb... to process characters would solve
> the problem?

Well, sure.  The problem is (1) finding all the places that need that
(I'd estimate dozens to hundreds of places in the core code, and then
there's the question of extensions); (2) preventing new
non-multibyte-aware code from being introduced after you've fixed those
places; and (3) the performance penalties you'd take, because a lot of
those places are bottlenecks and it's much cheaper to not worry about
character lengths in an inner loop.

> Isn't the current implementation blocking the support of
> other character sets that have similar characteristics?

Sure, SJIS is not the only encoding that we consider frontend-only.
See

https://www.postgresql.org/docs/devel/static/multibyte.html#MULTIBYTE-CHARSET-SUPPORTED

			regards, tom lane


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