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-598992058 > > > 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. OK. I could do that for something like unnest(employees) as t(e), but I am not sure what's a valid plan for unnest(employees, admins) as t(e, a). Can I just add one test case for something like unnest(employees) as t(e)? 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
