[
https://issues.apache.org/jira/browse/CALCITE-2404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16565109#comment-16565109
]
Stamatis Zampetakis commented on CALCITE-2404:
----------------------------------------------
I think it is relevant to discuss a bit more the changes around the DOT
operator.
According to its documentation "The dot operator is used to access a field of a
record." So a RexCall with a DOT operator is another way to model field access
without using the RexFieldAccess node. Without considering my changes we might
obtain plans that contain both to achieve the same purpose.
The test SqlToRelConverterTest.testArrayOfRecord is an example where the DOT
operator is used to model field access.
In my opinion, we shouldn't have two ways of performing the same thing. In that
direction, I am trying to make the DOT operator disappear from the plan.
However, this affects *backward compatibility* since plans that contained a
RexCall with the DOT operator will be now replaced with a RexFieldAccess.
Essentially, existing clients which go from logical to physical plans may fail
because of this new interpretation.
Fixing the test depends on if we want to incorporate or not the change above:
* if YES, then I have to modify the RelStructuredTypeFlattener
* if NO, then I have to modify the RexToLixTranslator
+Note+: currently the flattener does not do any particular handling of a
RexCall with a DOT operator (it just rewrites the call as is).
> Accessing structured-types is not implemented by the runtime
> ------------------------------------------------------------
>
> Key: CALCITE-2404
> URL: https://issues.apache.org/jira/browse/CALCITE-2404
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.17.0
> Reporter: Stamatis Zampetakis
> Assignee: Julian Hyde
> Priority: Blocker
>
> Queries on tables containing structured types cannot be executed by the
> Calcite runtime. A plan like the one that follows (taken from CALCITE-2220)
> can be translated to neither Bindable nor EnumerableConvention.
>
> {noformat}
> LogicalProject(EXPR$0=[$0])
> LogicalProject(EXPR$0$0=[ITEM($6, 1).EMPNO], EXPR$0$1=[ITEM($6, 1).ENAME],
> EXPR$0$2=[ITEM($6, 1).DETAIL])
> LogicalProject(DEPTNO=[$0], NAME=[$1], TYPE=[$2.TYPE], DESC=[$2.DESC],
> A=[$2.OTHERS.A], B=[$2.OTHERS.B], EMPLOYEES=[$3])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT_NESTED]])
> {noformat}
>
> More precisely, if a logical plan contains a RexFieldAccess expression that
> does not refer to a RexCorrelVariable it cannot be handled by the
> RexToLixTranslator. The translation will fail when calling
> [RexToLixTranslator#translate0|[https://github.com/apache/calcite/blob/5bbc501a565494442784f65870a20cd65a5016f4/core/src/main/java/org/apache/calcite/adapter/enumerable/RexToLixTranslator.java#L686]].
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
