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 | 7C2A735AFC3E4088A8F49B677855369C@maumau обсуждение исходный текст |
Ответ на | Re: UTF8 national character data type support WIP patch and list of open issues. (Greg Stark <stark@mit.edu>) |
Ответы |
Re: UTF8 national character data type support WIP patch and list of open issues.
|
Список | pgsql-hackers |
From: "Greg Stark" <stark@mit.edu> > If it's not lossy then what's the point? From the client's point of view > it'll be functionally equivalent to text then. Sorry, what Tatsuo san suggested meant was "same or compatible", not lossy. I quote the relevant part below. This is enough for the use case I mentioned in my previous mail several hours ago (actually, that is what Oracle manual describes...). http://www.postgresql.org/message-id/20130920.085853.1628917054830864151.t-ishii@sraoss.co.jp [Excerpt] ---------------------------------------- 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. ---------------------------------------- Regards MauMau
В списке pgsql-hackers по дате отправления: