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