[jira] Issue Comment Edited: (DERBY-3310) ASSERT in MergeSort.checkColumnTypes() disallow legal type conversions

["Daniel John Debrunner (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DERBY-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567247#action_12567247 ] 

djd edited comment on DERBY-3310 at 2/8/08 3:56 PM:
----------------------------------------------------------------------

In this *specific* case a cast is not needed, but I'm thinking more about the general case, so if it had been a case where conversion was needed
would the behaviour be correct?

So:
   is the assert wrong because the normalize node is doing the correct thing (e.g it knows INT -> IBIGNT is a safe conversion, no cast node needed),
   or is the assert correct and the normalize node is not putting in conversion code
   or is the normalize node and assert not related (my guess)

We are trying to insert a value of type A  into a column of type B, but there is the additional distinct step.
so the query is doing something like:

sort of (rows with value of type A)  ==> insert into table with column of type B

The assert is saying that at some point some types must match during a merge sort, which seems reasonable, but this would
be in the step before the normalize (which is the insert step). So why are the types different there?

      was (Author: djd):
    In this *specific* case a cast is not needed, but I'm thinking more about the general case, so if it had been a case where conversion was needed
would the behaviour be correct?

So:
   is the assert wrong because the normalize node is doing the correct thing (e.g it knows BIGINT -> INT is a safe conversion, no cast node needed),
   or is the assert correct and the normalize node is not putting in conversion code
   or is the normalize node and assert not related (my guess)

We are trying to insert a value of type A  into a column of type B, but there is the additional distinct step.
so the query is doing something like:

sort of (rows with value of type A)  ==> insert into table with column of type B

The assert is saying that at some point some types must match during a merge sort, which seems reasonable, but this would
be in the step before the normalize (which is the insert step). So why are the types different there?
  
> ASSERT in MergeSort.checkColumnTypes() disallow legal type conversions
> ----------------------------------------------------------------------
>
>                 Key: DERBY-3310
>                 URL: https://issues.apache.org/jira/browse/DERBY-3310
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.4.0.0
>            Reporter: Dyre Tjeldvoll
>            Priority: Minor
>         Attachments: cast-repro.sql
>
>
> The following code 
> CREATE TABLE U (SNAME VARCHAR(32000), TNAME VARCHAR(32000), C1 BIGINT);
> -- This triggers an ASSERT (because 2 is INTEGER and not BIGINT)
> INSERT INTO U(SNAME, TNAME, C1) SELECT DISTINCT SCHEMANAME, TABLENAME, 2
>  FROM SYS.SYSTABLES T JOIN SYS.SYSSCHEMAS S ON T.SCHEMAID = S.SCHEMAID;
> gives
> ERROR XJ001: Java exception: 'ASSERT FAILED col1.getClass() (class org.apache.derby.iapi.types.SQLInteger) expected to be the same as col2.getClass() (class org.apache.derby.iapi.types.SQLLongint): org.apache.derby.shared.common.sanity.AssertFailure'.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.