[
https://issues.apache.org/jira/browse/CALCITE-2404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16602710#comment-16602710
]
Stamatis Zampetakis commented on CALCITE-2404:
----------------------------------------------
Thanks for your comments [~vladimirsitnikov].
I agree with everything you say.
RE1) As I wrote above InputGetter and PhysType were among the first things I
considered. In fact, I have a solution in mind that makes use of these APIs but
has also various drawbacks/limitations.
The most important limitation is that the RexNode expression, which we want to
translate, must be composed only from RexFieldAccess paths that finish up in a
RexInputRef. If that's not the case, consider for example that there is a
RexCall expression somewhere in the middle, then the PhysType may have changed
and we can no longer use it. To illustrate this with an actual example imagine
that the RexCall is an ITEM operator or a ROW constructor. This call changes
the PhysType that is already built but this is not handled by the existing
code. Moreover to built a new PhysType somewhere in the middle is not
straightforward either.
RE2) In the initial PR, I was using Class#getFileds() to be inline with the
code in JavaTypeFactoryImpl but I changed this after your initial review.
Unfortunately, for the reasons I explained above, it is difficult to remove
SqlFunctions#structAccess.
> 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)
