my7ym commented on issue #1811: [CALCITE-3789] Support validation of UNNEST multiple array columns like Presto URL: https://github.com/apache/calcite/pull/1811#issuecomment-605682367 > > > We should also add a test case for at least one SqlToRelConverterTest. > > > > > > Will do it in the future if needed. I am still unclear that how this should be represented as RelNode. (discussed in https://issues.apache.org/jira/browse/CALCITE-3787) > > Is it OK for you? > > EDIT: Some other reasons: > > > > 1. We still plan to communicate with Presto using SQL. > > 2. RelNode -> SqlNode is not quite mature I believe, but I may be wrong there. > > 3. The optimization enabled by RelNode is helpful. But not a high-pri since Presto will also optimize the internal execution plan. > > Usually we have 2 kinds of use cases for Calcite: > > * Generates RelNode/RexNode to adapter other downstream planners > * Generates RelNode/RexNode and unparse it as special SQL dialect to interpretation through JDBC. > > Either way we should generates a working plan, that is why I suggest to add SqlToRel test. For more general, we should add operator test and SQL ITCase if we change an operator semantics. But for you case, I think a SqlToRelConverter test is okey. I have added tests for it. But it needs changes on SqlToRelConverter. The change is because usually for STRUCT, Uncollect will flatten the type but for this feature, it should not. This is also aligned with the registered type during validation. I am not sure whether this should be the best way to implement it. Let me know. Thanks.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
