[
https://issues.apache.org/jira/browse/CALCITE-2404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16618051#comment-16618051
]
Vladimir Sitnikov commented on CALCITE-2404:
--------------------------------------------
What bothers me is this change introduces unspoken rule of "struct must be
either X or Y or Z".
I would rather suggest having clearly defined ways to tell how the struct
should be represented.
{quote} If we can at least write them down here then we can solve them in
future work.{quote}
Adding public API is not the same as fixing a bug.
For instance, we might probably want to add a method like `getPhysType` to
`org.apache.calcite.schema.ImplementableFunction`.
Then ScalarFunctionImpl could override it with `method.getReturnType()` or
something like that.
In other words: known to Calcite functions that happen to return structs might
be supported now, and user-provided ones would fail (like they did) unless user
overrides `ImplementableFunction#getPhysType`.
On the other hand, I don't think `ImplementableFunction` is used heavily in the
wild.
> 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)
