From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | MauMau <maumau307(at)gmail(dot)com> |
Cc: | robertmhaas(at)gmail(dot)com, Tatsuo Ishii <ishii(at)postgresql(dot)org>, tgl(at)sss(dot)pgh(dot)pa(dot)us, maksymb(at)fast(dot)au(dot)fujitsu(dot)com, hlinnakangas(at)vmware(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: UTF8 national character data type support WIP patch and list of open issues. |
Date: | 2013-09-25 02:49:57 |
Message-ID: | 1380077397.1440.25.camel@vanquo.pezone.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2013-09-24 at 21:04 +0900, MauMau wrote:
> "4. I guess some users really want to continue to use ShiftJIS or EUC_JP for
> database encoding, and use NCHAR for a limited set of columns to store
> international text in Unicode:
> - to avoid code conversion between the server and the client for performance
> - because ShiftJIS and EUC_JP require less amount of storage (2 bytes for
> most Kanji) than UTF-8 (3 bytes)
> This use case is described in chapter 6 of "Oracle Database Globalization
> Support Guide"."
But your proposal wouldn't address the first point, because data would
have to go client -> server -> NCHAR.
The second point is valid, but it's going to be an awful amount of work
for that limited result.
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2013-09-25 03:18:23 | Re: dynamic shared memory |
Previous Message | Peter Eisentraut | 2013-09-25 02:40:58 | Re: ENABLE/DISABLE CONSTRAINT NAME |