From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
---|---|
To: | peter_e(at)gmx(dot)net |
Cc: | tim(at)proximity(dot)com(dot)au, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Vague idea for allowing per-column locale |
Date: | 2001-08-14 01:02:41 |
Message-ID: | 20010814100241X.t-ishii@sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > It'd be even nicer if you could make a table that has, say, one column
> > utf8 (or utf32 even), one column euc-jp and one column shift-jis, so
> > that you could cache format conversions.
>
> This might be a nice thing to show off but I'm not sure about the
> practical use. There's Unicode that you can use if you want to mix and
> match on the server, and the ability to convert the character set between
> client and server so the right thing shows up on everyone's screen.
Storing everything as Unicode is not a good idea, actually. First,
Unicode tends to consume more storage space than other character
sets. For example, UTF-8, one of the most commonly used encoding for
Unicode consumes 3 bytes for Japanese characters, while SJIS only
consumes 2 bytes. Second, a round trip converison between Unicode and
other character sets is not always possible. Third, sorting
issue. There is no convenient way to sort Unicode correctly.
--
Tatsuo Ishii
From | Date | Subject | |
---|---|---|---|
Next Message | Horst Herb | 2001-08-14 01:03:30 | Re: Surviving transaction-ID wraparound, take 2 |
Previous Message | Paul Ramsey | 2001-08-14 00:08:54 | Re: PostGIS spatial extensions |