Thanks for posting your solution. I can see why “WHERE 1 = 2” worked better than “LIMIT 0”; it is closer to the LogicalValues node, and therefore had greater chance of being combined using the default rules.
I’d write “WHERE FALSE”; for some reason folks are afraid to admit that BOOLEAN is a first-class type. Though it’s not the question you asked, if you happen to be building relational expressions using RelBuilder, note that you can create an empty Values directly using RelBuilder.values(RelDataType) [1]. Julian [1] https://calcite.apache.org/apidocs/org/apache/calcite/tools/RelBuilder.html#values-org.apache.calcite.rel.type.RelDataType- <https://calcite.apache.org/apidocs/org/apache/calcite/tools/RelBuilder.html#values-org.apache.calcite.rel.type.RelDataType-> > On May 17, 2019, at 8:56 AM, Anton Haidai <[email protected]> wrote: > > As it turned out, a combination on "where 1=2" and > "FilterReduceExpressionsRule" works fine for my purposes, a code > sample could be found in the ticket description: > https://issues.apache.org/jira/browse/CALCITE-3076 > > On Fri, May 17, 2019 at 6:05 PM Anton Haidai <[email protected]> wrote: >> >> Hello, >> I'm trying to reproduce a tricky bug in RelOptRulesTest. It requires >> an empty LogicalValues with a desired row type to be a direct input of >> a join. I can achieve the desired structure using RelBuilder and >> LogicalValues.createEmpty(), however, I can't reproduce it in test's >> SQL. For example, SQL "select 42 sal, 'Bobby' ename LIMIT 0" produces >> the following logical plan: >> >> LogicalSort(fetch=[0]) >> LogicalValues(tuples=[[]]) >> >> But I need only the LogicalValues node, without LogicalSort or any >> other nodes on top of it. >> I have a workaround that replaces the nodes by means of a dedicated >> rule in preProgram, but this solution looks really poor. >> >> Possibly, there is some trick to define just an empty LogicalValues >> with a desired row type using SQL only? >> >> -- >> Best regards, >> Anton. > > > > -- > Best regards, > Anton.
