db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Db-derby Wiki] Update of "BuiltInLanguageBasedOrderingDERBY-1478" by DanDebrunner
Date Mon, 04 Jun 2007 19:22:54 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.

The following page has been changed by DanDebrunner:
http://wiki.apache.org/db-derby/BuiltInLanguageBasedOrderingDERBY-1478

------------------------------------------------------------------------------
  http://www.nabble.com/Collation-implementation-WAS-Re%3A-Should-COLLATION-attribute-related-code-go-in-BasicDatabase--p9496608.html
  
  == Collation Determination ==
- In Derby 10.3, there will be two character sets associated with the database. These 2 character
sets will have identical character repertoire(UCS) but they may have different collation associated
with them depending on the value of JDBC url attribute COLLATION. The 2 character sets will
be 
+ In Derby 10.3, there will be two character sets associated with the database. These 2 character
sets will have identical character repertoire(UCS) but they may have different default collation
associated with them depending on the value of JDBC url attribute COLLATION. The 2 character
sets will be 
  
- a)USER character set - collation of UCS_BASIC/TERRITORY_BASED depending on the value of
jdbc url attribute COLLATION specified at create database time.
+ a)USER character set - default collation of UCS_BASIC/TERRITORY_BASED depending on the value
of jdbc url attribute COLLATION specified at create database time.
  
- b)SQL_IDENTIFIER character set - collation of UCS_BASIC.
+ b)SQL_IDENTIFIER character set - default collation of UCS_BASIC.
+ 
+ (Section 4.2.7 indicates a character set has a default collation).
  
  As per SQL spec, Section 11.1<schema definition>, there is an optional syntax to associate
a character set for a schema at create schema time. Syntax Rule 5 says that if a character
set is not specified by the user, then the character set associated with schema is implementation
defined. In Derby 10.3, system schemas will be associated with SQL_IDENTIFER character set
and all the user schemas will be associated with USER character set. Futher on, General Rule
3 specifies that the character set associated with schema is used as the default character
set for all <column definitions>. Based on this, all the user character columns will
pick up the collation associated with USER character set and all the system character columns
will pick the up the collation associated with SQL_IDENTIFIER character set. 
+ 
+ Following section 11.4 SR10b) it is '''as though''' any user character column is defined
using `CHARACTER SET USER` and any system column using `CHARACTER SET SQL_IDENTIFIER`. E.g.
+ {{{
+   CREATE TABLE T (NAME VARCHAR(100))
+ }}}
+ is equivalent for the purposes of the SQL Standard to this:
+ {{{
+   CREATE TABLE T (NAME VARCHAR(100) CHARACTER SET USER)
+ }}}
+ Note Derby does not actually support the CHARACTER SET clause.
   
  The character set specification for string literals in SQL specification is not as well
defined as for <column definitions>. SQL spec Section 5.3<literal>, Syntax Rule
14b says that if the character set is not specified for character string literal, then character
string literal's character set will be the character set of the SQL-client module. Derby does
not implement SQL-client module, but definition of SQL-client module in Section 13.1 says
that SQL-client module definition has mandatory <module name clause> which is defined
in Section 13.2 <module name clause>. The Syntax Rule 4 in this section says that if
a character set is not specified for the SQL-client module, then it's character set is "implementation-defined".
For Derby, this implementation-defined character set for SQL-client module will be USER. And
hence the string literals will have the USER character set associated with them.
  

Mime
View raw message