[
https://issues.apache.org/jira/browse/DERBY-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12570761#action_12570761
]
Bryan Pendleton commented on DERBY-3310:
----------------------------------------
If the "immediate child result" of the InsertNode is a Normalize node,
then I think the VCN instances for the columns in the InsertNode
should have sourceResultSet pointing to a NormalizeResultSet,
and sourceColumn pointing to a column in the NRS's ResultColumnList.
In that case, it seems correct for that sourceColumn to be of type longint,
because it represents the *result* of the normalization.
That is:
- the PRN should sort values with integer type, and feed them up to the NRSN
- the NRS should invoke normalizeRow() to convert the int to a long
- the InsertNode should pull long values from the NRS and insert them
into the target table.
However, it looks like maybe this was the intent of the design, but
never completed? Here's a snip from a comment in NormalizeResultSet.java:
* Normalize a row. For now, this means calling constructors through
* the type services to normalize a type to itself. For example,
* if you're putting a char(30) value into a char(15) column, it
* calls a SQLChar constructor with the char(30) value, and the
* constructor truncates the value and makes sure that no non-blank
* characters are truncated.
*
* In the future, this mechanism will be extended to do type conversions
* as well. I didn't implement type conversions yet because it looks
* like a lot of work, and we needed char and varchar right away.
As I said before, though, I'm just guessing. It would be good to have some more
eyes and thoughts on how this is supposed to behave.
> 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.
