[
https://issues.apache.org/jira/browse/CALCITE-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-1278.
----------------------------------
Resolution: Fixed
Fix Version/s: 1.9.0
Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/76616379.
[~maryannxue], thanks for the patch!
> CalciteSignature's ColumnMetaData for DELETE should be same as INSERT
> ---------------------------------------------------------------------
>
> Key: CALCITE-1278
> URL: https://issues.apache.org/jira/browse/CALCITE-1278
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.7.0
> Reporter: Maryann Xue
> Assignee: Maryann Xue
> Fix For: 1.9.0
>
> Attachments: CALCITE-1278.patch
>
>
> DELETE, as one type of TableModify operation, has the same RelDataType as
> INSERT, which is RelRecordType(ROWCOUNT INTEGER). But during "prepare" stage,
> the corresponding ColumnMetaData info becomes inconsistent, due to:
> {code}
> preparedResult = preparingStmt.prepareSql(
> sqlNode, Object.class, validator, true);
> switch (sqlNode.getKind()) {
> case INSERT:
> case EXPLAIN:
> // FIXME: getValidatedNodeType is wrong for DML
> x = RelOptUtil.createDmlRowType(sqlNode.getKind(), typeFactory);
> break;
> default:
> x = validator.getValidatedNodeType(sqlNode);
> }
> {code}
> I've noticed that there is a "FIXME: getValidatedNodeType is wrong for DML".
> Guess that's the root cause, and RelOptUtil.createDmlRowType() is probably a
> workaround? For now, we can simply include DELETE and other TableModify
> Operation in the first switch case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
