We have support for this in planner rules -- I’m pretty sure that ReduceExpressionsRule.FILTER_INSTANCE will convert ‘where 1 = 0’ to ‘where false’, then PruneEmptyRules.FILTER_INSTANCE will make the Filter disappear altogether — but arguably it could happen in RexUtil.simplify also.
The purpose of RexUtil.simplify is to simplify (only) patterns that are commonly occurring, easy to recognize, and will produce a quick win in terms of the size of the RelNode/RexNode tree. I don’t know yet whether this passes that threshold. Can you log a JIRA case for this and we can discuss further? By the way, https://issues.apache.org/jira/browse/CALCITE-1638 <https://issues.apache.org/jira/browse/CALCITE-1638> is related. It changed the result of a test that was doing ‘where 1 = 1’. Julian > On Feb 19, 2017, at 2:03 PM, Kevin Risden <[email protected]> wrote: > > While working on Solr and Calcite integration, I found that there is a case > where some tools issue a sql query like "where 1 = 0" just to get metadata > information back. Spark SQL is one of the ones that does this. > > Calcite doesn't seem to optimize away the literal comparison literal case > with RexUtil.simplify. In my understanding any literal comparison literal > results in a simple TRUE/FALSE result. > > I'm not sure this is valid in the general case, but I put together a simple > example of doing this on the RexUtil simplifyCall. > > https://github.com/apache/calcite/pull/376 > > I would love to hear any feedback related to this. I need to run through > the full Calcite test suite, but wondering if this is even viable. > > Thanks! > > Kevin Risden
