[
https://issues.apache.org/jira/browse/DERBY-2879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509612
]
Mamta A. Satoor commented on DERBY-2879:
----------------------------------------
I have checked in following code in CreateTableNode
+ (schemaCollationType ==
+
StringDataValue.COLLATION_TYPE_UCS_BASIC ?
+ Property.UCS_BASIC_COLLATION :
+ Property.TERRITORY_BASED_COLLATION);
Basically, the code above is trying to find the string representation for the
int collation type so that string can be used in the exception that will be
thrown. There is similar code to get string representation from the
TypeDescriptor's collaiton type in TypeDescriptorImpl.java which is as follows
public String getCollationName()
{
return(
collationType == StringDataValue.COLLATION_TYPE_UCS_BASIC ?
Property.UCS_BASIC_COLLATION :
Property.TERRITORY_BASED_COLLATION);
}
I wonder if there is any common utility class where I can move this logic from
TypeDescriptorImpl and CreateTableNode so the code is not duplicated. Please
let me know if there is any recommendation for where I can move this code.
> CREATE TABLE AS <subquery> does not maintain the collation for character
> types.
> -------------------------------------------------------------------------------
>
> Key: DERBY-2879
> URL: https://issues.apache.org/jira/browse/DERBY-2879
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.3.1.0, 10.3.1.1, 10.4.0.0
> Reporter: Daniel John Debrunner
> Assignee: Mamta A. Satoor
> Priority: Critical
>
> create table t as select tablename from sys.systables with no data;
> This creates a column TABLENAME with collation based upon the user schema,
> but the type of sys.systables.tablename has collation UCS_BASIC.
> The required behaviour should be verified with the SQL standard (11.3 SR6),
> but since collation is an attribute of a type it seems logical that the
> collation is maintained by the create.
> Fixing this to keep the collation of the system column will cause problems
> though as there would be no way to recreate this table through a regular
> create table, say if the schema is dumped and recreated using ddlutils.
> I think this is critical as fixing it after a release would lead to a change
> in behaviour for applications.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
