zabetak commented on a change in pull request #1152: [CALCITE-2962]
RelStructuredTypeFlattener generates wrong types for n…
URL: https://github.com/apache/calcite/pull/1152#discussion_r275135844
##########
File path:
core/src/test/resources/org/apache/calcite/test/SqlToRelConverterTest.xml
##########
@@ -867,6 +867,17 @@ LogicalProject(ZIP=[$4])
LogicalFilter(condition=[=($3, 'abc':VARCHAR(20))])
LogicalProject(EMPNO=[$0], STREET=[$1.STREET], CITY=[$1.CITY],
ZIP=[$1.ZIP], STATE=[$1.STATE], STREET5=[$2.STREET], CITY6=[$2.CITY],
ZIP7=[$2.ZIP], STATE8=[$2.STATE])
LogicalTableScan(table=[[CATALOG, SALES, EMP_ADDRESS]])
+]]>
+ </Resource>
+ </TestCase>
+ <TestCase name="testSelectNestedColumnType">
+ <Resource name="plan">
+ <![CDATA[
+LogicalProject(COORD=[$0])
Review comment:
The root is used to remove redundant fields that may be introduced for
various reasons. For instance, the fields participating in an ORDER BY clause
will appear in the project even if they don't appear in the SELECT clause; in
that case the root will be used to remove these fields before returning the
answer to the user.
As you say the problem is probably in another part of the code, but I would
prefer if we could find another test that reproduces the problem and also has a
correct plan. Apparently, thats not easy since I tried but with no success till
now. I will give it some more thought and if we don't find a better test, I
will merge this as is ;)
In general, this use-case makes me wonder a bit. What is the purpose of the
type flattener if at the end we need to return an unflattened type.
----------------------------------------------------------------
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
