From: "Greg Stark" <st...@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-is...@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
