rubenada commented on a change in pull request #2141: URL: https://github.com/apache/calcite/pull/2141#discussion_r485429428
########## File path: core/src/main/java/org/apache/calcite/rex/RexCall.java ########## @@ -80,7 +80,6 @@ protected RexCall( this.nodeCount = RexUtil.nodeCount(1, this.operands); assert op.getKind() != null : op; assert op.validRexOperands(operands.size(), Litmus.THROW) : this; - assert op.kind != SqlKind.IN || this instanceof RexSubQuery; Review comment: > This isn't 'sudden'. For years I've been arguing in favor of expanding SQL IN lists to ORs. One thing is expanding IN lists to ORs (which I think is totally fine, and Calcite should continue doing it), and a different thing is forbidding creating an IN list call (which is the "new" change introduced by CALCITE-4173). > This isn't 'drastic'. Most people aren't using this. I do not know about "most people", I know that my application is using it. In my specific example, even though IN lists are expanded as ORs, under certain circumstances my application re-contracts them again as an IN list. The reason for that is allowing to execute later an IndexScan exploiting some Lucene indices, where the IN list call can be implemented as a Lucene's TermInSetQuery. Other applications can have other use cases, but I would say that having the possibly to define an IN list call in relational algebra is something useful that should not be forbidden. ---------------------------------------------------------------- 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: us...@infra.apache.org