Can you please log this? It might be useful if you create a PR with a single commit to represent the test case.
We can discuss workarounds or fixes in the jira case. > On Mar 2, 2023, at 11:44 AM, Andrew Pilloud <[email protected]> > wrote: > > A Beam user brought us a query that produces an invalid plan after > upgrading to a newer version of Beam (moving them from Calcite 1.20 to > 1.28). I was able to write a test case which demonstrates this issue > with a trivial filter on a table containing a nested struct with a > single field. The issue appears to be coming out of > RelStructuredTypeFlattener.rewrite and I bisected it to a single > commit: > https://github.com/apache/calcite/commit/e44beba286ea9049c5fd00c3a3b0e4a4f1c03356 > > Removing the noFlatteningForInput function added in this commit fixes > the issue. That method doesn't appear to be looking at types at all, > only mismatches in field count, I expect so any single field struct > would hit this. Any suggestions on how we can work around this in > Beam? > > The test query and plans are as follows, the test case is attached. > > select dn.skill from sales.dept_single dn WHERE dn.skill.type = '' > > Expected plan: > LogicalProject(SKILL=[ROW($0)]) > LogicalFilter(condition=[=($0, '')]) > LogicalProject(TYPE=[$0.TYPE]) > LogicalTableScan(table=[[CATALOG, SALES, DEPT_SINGLE]]) > > Actual Plan: > LogicalProject(SKILL=[ROW($0)]) > LogicalFilter(condition=[=($0.TYPE, '')]) > LogicalProject(TYPE=[$0.TYPE]) > LogicalTableScan(table=[[CATALOG, SALES, DEPT_SINGLE]]) > > Plan before flatten: > LogicalProject(SKILL=[$0]) > LogicalFilter(condition=[=($0.TYPE, '')]) > LogicalTableScan(table=[[CATALOG, SALES, DEPT_SINGLE]]) > <wrongplan.patch>
