db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A B (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3310) ASSERT in MergeSort.checkColumnTypes() disallow legal type conversions
Date Sat, 08 Mar 2008 00:15:46 GMT

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

A B commented on DERBY-3310:
----------------------------

Dan> I don't think the ResultSetNode R should be modified. It's a very unnatural coding
style,
Dan> subject to bugs, e.g. with the code as-is any other node that thinks it is pointing
to R's
Dan> ResultColumns silently gets changed to be pointing to NR's ResultColumns.

After doing a bit of investigation for DERBY-3494, I think this "silent update" effect is
precisely
*why* ResultSetNode R is being modified.  That is, if there is some column reference pointing
to R's ResultColumns and then additional nodes are generated on top of R, it appears that
those column references *must* point to the "top" of the newly-generated nodes instead of
to R.  At least, that appears to be what execution-time logic expects (see DERBY-3494).

So the execution code _expects_ that any ColumnReference node which thinks it is pointing
to R's ResultColumns _is_ silently changed to point to the NR's result columns.  It may be
"unnatural" and "subject to bugs", but this particular "side effect" looks to be intentional.
 Not
good, necessarily, but intentional...

I'm not saying anything else about this particular issue (I still need to catch up on the
discussion),
but I thought I'd throw that out there.  Apologies if it's irrelevant.

> 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, derby-3310_remove_genNormalizeResultSetNode_diff.txt,
derby-3310_try1_diff.txt, derby3310_rsn_cleanup_1.txt
>
>
> 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