[ http://issues.apache.org/jira/browse/DERBY-533?page=comments#action_12414625 ]
Satheesh Bandaram commented on DERBY-533: ----------------------------------------- I have some interest in enabling National character types in Derby for 10.2. I am following all the previous discussions on this subject. My itch is primarily on the SQL side and I haven't decided whether to provide JDBC3 or JDBC4 API support. Since JDBC4 has added support for national character types and ability to set/get data of these types and added JDBC type constants for these. I don't have itch to implement JDBC4 support, so, I am currently thinking of enabling national types and adding JDBC3 API support for these. I am still at very early stage and would like to submit a functional specification soon. > Re-enable national character datatypes > -------------------------------------- > > Key: DERBY-533 > URL: http://issues.apache.org/jira/browse/DERBY-533 > Project: Derby > Type: New Feature > Components: SQL > Versions: 10.1.1.0 > Reporter: Rick Hillegas > > SQL 2003 coyly defines national character types as "implementation defined". > Accordingly, there is considerable variability in how these datatypes behave. > Oracle and MySQL use these datatypes to store unicode strings. This would not > distinguish national from non-national character types in Derby since Derby > stores all strings as unicode sequences. > The national character datatypes (NCHAR, NVARCHAR, NCLOB and their synonymns) > used to exist in Cloudscape but were disabled in Derby. The disabling comment > in the grammar says "need to re-enable according to SQL standard". Does this > mean that the types were removed because they chafed against SQL 2003? If so, > what are their defects? > ------------------------------------------------------------------ > Cloudscape 3.5 provided the following support for national character types: > - NCHAR and NVARCHAR were legal datatypes. > - Ordering operations on these datatypes was determined by the collating > sequence associated with the locale of the database. > - The locale was a DATABASE-wide property which could not be altered. > - Ordering on non-national character datatypes was lexicographic, that is, > character by character. > ------------------------------------------------------------------ > Oracle 9i provides the following support for national character types: > - NCHAR, NVARCHAR2, and NCLOB datatypes are used to store unicode strings. > - Sort order can be overridden per SESSION or even per QUERY, which means > that these overridden sort orders are not supported by indexes. > ------------------------------------------------------------------ > DB2 does not appear to support national character types. Nor does its DRDA > data interchange protocol. > ------------------------------------------------------------------ > MySQL provides the following support for national character types: > - National Char and National Varchar datatypes are used to hold unicode > strings. I cannot find a national CLOB type. > - The character set and sort order can be changed at SERVER-wide, TABLE-wide, > or COLUMN-specific levels. > ------------------------------------------------------------------ > If we removed the disabling logic in Derby, I believe that the following > would happen: > - We would get NCHAR, NVARCHAR, and NCLOB datatypes. > - These would sort according to the locale that was bound to the database > when it was created. > - We would have to build DRDA transport support for these types. > The difference between national and non-national datatypes would be their > sort order. > I am keenly interested in understanding what defects (other than DRDA > support) should be addressed in the disabled implementation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
