db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (DERBY-3310) ASSERT in MergeSort.checkColumnTypes() disallow legal type conversions
Date Fri, 08 Feb 2008 23:57:13 GMT

    [ 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.


Mime
View raw message