[
https://issues.apache.org/jira/browse/DERBY-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679905#action_12679905
]
Dag H. Wanvik commented on DERBY-4071:
--------------------------------------
I found I could simplify the query still further and get the error:
SELECT MAX(CHR) FROM DEMO.TEST T
GROUP BY T.VCHR
HAVING COUNT(T.VCHR) > 1
Stack trace extract:
.derby.shared.common.sanity.SanityManager.THROWASSERT(SanityManager.java:147)
.derby.impl.store.access.sort.MergeSort.checkColumnTypes(MergeSort.java:471)
.derby.impl.store.access.sort.MergeInserter.insert(MergeInserter.java:98)
.derby.impl.sql.execute.GroupedAggregateResultSet.loadSorter(GroupedAggregateResultSet.java:308)
.derby.impl.sql.execute.GroupedAggregateResultSet.openCore(GroupedAggregateResultSet.java:180)
.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(ProjectRestrictResultSet.java:168)
.derby.impl.sql.execute.BasicNoPutResultSetImpl.open(BasicNoPutResultSetImpl.java:245)
.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:416)
.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:297)
.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1235)
Just wanted to add a little more detail, my previous comment was too
brief, I was getting sleepy :)
The inputRow from the underlying ProjectRestrictResultSet has wrong
type for ##aggregate expression for the count aggregator: CHR in stead
of VCHAR, due to the mapArray containing the wrong virtual column (1)
instead of 2, due to wrong contents in mapArray[2] used by
ProjectRestrictNode ca line 1422, to set up the referenced column
descriptor for runtime. This is picked up by ProjectRestrictResultSet,
ca line 107 with the call to getReferencedColumnPositions.
These two lines in ProjectRestrictNode:
// Map the result columns to the source columns
int[] mapArray = resultColumns.mapSourceColumns();
pick up the virtual column ids from ProjectRestrictNode#resultColumns.
The third of those (index 2), the ##aggregate expression for COUNT, is
the one I referred to in my previous post.
It seems it is the fact that the aggregator input expression (for COUNT) is
also the column
we group by (a.k.a. ##UnaggColumn), which is the root of the problem here..
What do you think?
The group by rewriting is tricky..
> AssertFailure when selecting rows from a table with CHARACTER and VARCHAR
> columns
> ---------------------------------------------------------------------------------
>
> Key: DERBY-4071
> URL: https://issues.apache.org/jira/browse/DERBY-4071
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.4.2.0
> Reporter: Aaron Digulla
> Attachments: DerbyTest.java, trialPatch.diff
>
>
> When running a complex query on this table:
> [code]
> Create table DEMO.TEST (
> CHR CHARACTER(26) ,
> VCHR VARCHAR(25) )
> [code]
> then I get this exception:
> AssertFailure: ASSERT FAILED col1.getClass() (class ...SQLChar) expected to
> be the same as col2.getClass() (class ....SQLVarchar)' was thrown while
> evaluating an expression.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
