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 MamtaSatoor
Date Wed, 04 Apr 2007 14:15:56 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 MamtaSatoor:
http://wiki.apache.org/db-derby/BuiltInLanguageBasedOrderingDERBY-1478

------------------------------------------------------------------------------
  
  5)Result character string types from UPPER, LOWER, TRIM(LTRIM, RTRIM), SUBSTR will have
the same collation as their operand. This comes from SQL spec Section 6.29 <string value
function> Syntax Rules 8, 8, 11d, 4 respectively). The collation derivation will be implicit.

  
- 6)CHAR, VARCHAR functions do not look like they are defined in the SQL spec. But based on
5) above, the result character string type's collation can be considered same as the first
argument's collation type if the first argument to CHAR/VARCHAR function is a character string
type. If the first argument is not character string type, then the result character string
of CHAR/VARCHAR will have the same collation as current schema's character set. The collation
derivation will be implicit.
+ 6)CHAR, VARCHAR functions do not look like they are defined in the SQL spec. Their behavior
can be defined as similar to CAST ie, the result character string of CHAR/VARCHAR will have
the same collation as current schema's character set. The collation derivation will be implicit.
  
- '''[[GetText(Comment from Rick)]]''' The behavior will fall in SQL standard model if these
2 functions always returned a character string type with the collation of current schema's
character set. This will also be easier to implement and easier to explain to the user.
+ 7)For user defined functions' that return character string type, the return type's collation
will have the same collation as of the character set of the schema that the function is defined
in. The collation derivation will be implicit. 
  
+ 8)JDBC parameters (ie. ?) where the type of the parameter is a character type will have
the same collation as of the character set of the schema where the statement is prepared.
The collation derivation will be implicit. 
- 7)For user defined functions' that return character string type, the return type's collation
will have the same collation as current schema's character set. The collation derivation will
be implicit. 
- 
- '''[[GetText(Comment from Dan)]]''' The "current schema's" character set, or the character
set of the schema the function is defined in? And if it's the current schema, is it current
at function definition time, or current when used?
- 
- 8)JDBC parameters (ie. ?) where the type of the parameter is a character type will have
the same collation as current schema's character set, based on 3) above.
- 
- '''[[GetText(Comment from Army)]]''' Using the character set of the schema where the statement
is prepared will make the behavior consistent rather than using the character set of the schema
where the prepared statement is executed.
  
  9)For CURRENT_USER, SESSION_USER, SYSTEM_USER, SQL spec Section 6.4 Syntax Rule 4 says that
their collation type is the collation of character set SQL_IDENTIFIER. In Derby's case, that
will mean, the collation of these functions will be UCS_BASIC. The collation derivation will
be implicit. 
  
@@ -136, +130 @@

  1)Make sure the space padding at the end of various character datatypes is implemented commented
correctly in javadocs. This padding is used in collation related methods. For eg check SQLChar.stringCompare
method.
  
  == Implemented items ==
+ Type system
  1)Subclasses with non-default-collation have been implemented for character types SQLChar,
SQLVarchar, SQLLongvarchar and SQLClob. The new subcalsses are called CollatorSQLChar, CollatorSQLVarchar,
CollatorSQLLongvarchar and CollatorSQLClob, respectively. They reside in derby.iapi.types
package. This work was done by revisions 516864, 516869 and 518479, 524545.
  
+ Boot time
- 2)At the time of database create time, optional JDBC url attribute COLLATION is validated
by the boot code in data dictionary and the validated value of COLLATION(if none specified
by user, then it will default to UCS_BASIC which is also the only collation available on pre-10.3
databases) attribute is saved as derby.database.collation property in the properties conglomerate.
This work was done by revision 511283
+ 1)At the time of database create time, optional JDBC url attribute COLLATION is validated
by the boot code in data dictionary and the validated value of COLLATION(if none specified
by user, then it will default to UCS_BASIC which is also the only collation available on pre-10.3
databases) attribute is saved as derby.database.collation property in the properties conglomerate.
This work was done by revision 511283
  
  == Related Pages ==
  

Mime
View raw message