| From: | "MauMau" <maumau307(at)gmail(dot)com> |
|---|---|
| To: | <robertmhaas(at)gmail(dot)com>, "Tatsuo Ishii" <ishii(at)postgresql(dot)org> |
| Cc: | <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-20 23:33:28 |
| Message-ID: | 225725531CAD4DA6AAED8F4F3F8EFF94@maumau |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
From: "Tatsuo Ishii" <ishii(at)postgresql(dot)org>
> What about limiting to use NCHAR with a database which has same
> encoding or "compatible" encoding (on which the encoding conversion is
> defined)? This way, NCHAR text can be automatically converted from
> NCHAR to the database encoding in the server side thus we can treat
> NCHAR exactly same as CHAR afterward. I suppose what encoding is used
> for NCHAR should be defined in initdb time or creation of the database
> (if we allow this, we need to add a new column to know what encoding
> is used for NCHAR).
>
> For example, "CREATE TABLE t1(t NCHAR(10))" will succeed if NCHAR is
> UTF-8 and database encoding is UTF-8. Even succeed if NCHAR is
> SHIFT-JIS and database encoding is UTF-8 because there is a conversion
> between UTF-8 and SHIFT-JIS. However will not succeed if NCHAR is
> SHIFT-JIS and database encoding is ISO-8859-1 because there's no
> conversion between them.
Thanks for the idea, it sounds flexible for wider use. Your cooperation
would be much appreciated to devise implementation with as little code as
possible.
Regards
MauMau
| From | Date | Subject | |
|---|---|---|---|
| Next Message | MauMau | 2013-09-20 23:58:15 | Re: UTF8 national character data type support WIP patch and list of open issues. |
| Previous Message | Josh Berkus | 2013-09-20 22:56:24 | Re: Could ANALYZE estimate bloat? |