[jira] Commented: (DERBY-2959) create table ... as select ... from systemtable with no data fails even when there is no character string type involved. This happens in a territory based database
[ https://issues.apache.org/jira/browse/DERBY-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514684 ] Mamta A. Satoor commented on DERBY-2959: Changed the commit comments for the fixes that went into main and 10.3.1.3 to include the proper jira entry rather than DERBY-2656. Thanks to Myrna for pointing it out. create table ... as select ... from systemtable with no data fails even when there is no character string type involved. This happens in a territory based database --- Key: DERBY-2959 URL: https://issues.apache.org/jira/browse/DERBY-2959 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.3.0.0 Reporter: Mamta A. Satoor Assignee: Mamta A. Satoor Fix For: 10.3.1.3, 10.4.0.0 Following query should fail because we are trying to create a user table with UCS_BASIC character columns when the user schema has collation of territory based. CREATE TABLE T AS SELECT TABLENAME FROM SYS.SYSTABLES WITH NO DATA But the following query should not fail because there are no character string columns involved. This jira entry is to fix the exception that is getting thrown for the query below CREATE TABLE T AS SELECT COLUMNNUMBER FROM SYS.SYSCOLUMNS WITH NO DATA I have put in a fix for this in main using revision 557693. The commit comments were as follows This commit has 2 simple fixes (DERBY-2951 which gives assert failure and DERBY-2656 The table will have collation type UCS_BASIC which is different than the collation of the schema TERRITORY_BASED hence this operation is not supported.) The failure in DERBY-2951 is because in store, we were not using correct format id and hence collation information was not getting written out and read from disk. Added a test case for this in CollationTest. The failure in DERBY-2656 was because of the bug that we were comparing collation type for non-character types. Collation is only applicable to character types and hence we should check for character types before comparing the collation info. Added a test case for this one too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2959) create table ... as select ... from systemtable with no data fails even when there is no character string type involved. This happens in a territory based database
[ https://issues.apache.org/jira/browse/DERBY-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513966 ] Mamta A. Satoor commented on DERBY-2959: Merged change into 10.3 codeline using revision 557716 create table ... as select ... from systemtable with no data fails even when there is no character string type involved. This happens in a territory based database --- Key: DERBY-2959 URL: https://issues.apache.org/jira/browse/DERBY-2959 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.3.0.0 Reporter: Mamta A. Satoor Assignee: Mamta A. Satoor Following query should fail because we are trying to create a user table with UCS_BASIC character columns when the user schema has collation of territory based. CREATE TABLE T AS SELECT TABLENAME FROM SYS.SYSTABLES WITH NO DATA But the following query should not fail because there are no character string columns involved. This jira entry is to fix the exception that is getting thrown for the query below CREATE TABLE T AS SELECT COLUMNNUMBER FROM SYS.SYSCOLUMNS WITH NO DATA I have put in a fix for this in main using revision 557693. The commit comments were as follows This commit has 2 simple fixes (DERBY-2951 which gives assert failure and DERBY-2656 The table will have collation type UCS_BASIC which is different than the collation of the schema TERRITORY_BASED hence this operation is not supported.) The failure in DERBY-2951 is because in store, we were not using correct format id and hence collation information was not getting written out and read from disk. Added a test case for this in CollationTest. The failure in DERBY-2656 was because of the bug that we were comparing collation type for non-character types. Collation is only applicable to character types and hence we should check for character types before comparing the collation info. Added a test case for this one too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
