| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
| Cc: | "'Tatsuo Ishii'" <ishii(at)sraoss(dot)co(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Supporting SJIS as a database encoding |
| Date: | 2016-09-06 03:10:14 |
| Message-ID: | 27598.1473131414@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kyotaro HORIGUCHI | 2016-09-06 03:29:04 | Re: Supporting SJIS as a database encoding |
| Previous Message | Tsunakawa, Takayuki | 2016-09-06 02:57:01 | Re: Supporting SJIS as a database encoding |