Re: UTF8 national character data type support WIP patch and list of open issues.
От | MauMau |
---|---|
Тема | Re: UTF8 national character data type support WIP patch and list of open issues. |
Дата | |
Msg-id | 7DCFAE8265254605840917B35EEF09F1@maumau обсуждение исходный текст |
Ответ на | Re: UTF8 national character data type support WIP patch and list of open issues. (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: UTF8 national character data type support WIP patch
and list of open issues.
Re: UTF8 national character data type support WIP patch and list of open issues. |
Список | pgsql-hackers |
From: "Peter Eisentraut" <peter_e@gmx.net> > That assumes that the conversion client encoding -> server encoding -> > NCHAR encoding is not lossy. Yes, so Tatsuo san suggested to restrict server encoding <-> NCHAR encoding combination to those with lossless conversion. > I thought one main point of this exercise > was the avoid these conversions and be able to go straight from client > encoding into NCHAR. It's slightly different. Please see the following excerpt: http://www.postgresql.org/message-id/B1A7485194DE4FDAB8FA781AFB570079@maumau "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"." Regards MauMau
В списке pgsql-hackers по дате отправления: