[ http://issues.apache.org/jira/browse/DERBY-533?page=comments#action_12414786 ]
Rick Hillegas commented on DERBY-533: ------------------------------------- Hi Satheesh, I'm looking forward to seeing your spec. I cooled on the idea of re-enabling these datatypes after it seemed to me that their real value was that they enabled locale-specific sort orders. The SQL language for collations seemed to me to be a more flexible (although considerably more expensive) solution. I don't understand the implications of checking in these datatypes without building the corresponding JDBC4 support. I hadn't planned to build that support for 10.2. It may mean that we can't claim we're JDBC4 compliant. > 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
