Re: UTF8 national character data type support WIP patch and list of open issues.
От | Arulappan, Arul Shaji |
---|---|
Тема | Re: UTF8 national character data type support WIP patch and list of open issues. |
Дата | |
Msg-id | 022C711CCA8AF2459F370E936F2B9E8C0255E4BB@SYDExchTmp.au.fjanz.com обсуждение исходный текст |
Ответ на | Re: UTF8 national character data type support WIP patch and list of open issues. ("MauMau" <maumau307@gmail.com>) |
Ответы |
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 |
Attached is a patch that implements the first set of changes discussed in this thread originally. They are: (i) Implements NCHAR/NVARCHAR as distinct data types, not as synonyms so that: - psql \d can display the user-specified data types. - pg_dump/pg_dumpall can output NCHAR/NVARCHAR columns as-is, not as CHAR/VARCHAR. - Groundwork to implement additional features for NCHAR/NVARCHAR in the future (For eg: separate encoding for nchar columns). (ii) Support for NCHAR/NVARCHAR in ECPG (iii) Documentation changes to reflect the new data type Rgds, Arul Shaji >-----Original Message----- >From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers- >owner@postgresql.org] On Behalf Of MauMau > >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.162891705483086415 1.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 > > > >-- >Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make >changes to your subscription: >http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
В списке pgsql-hackers по дате отправления: