julianhyde commented on a change in pull request #2141:
URL: https://github.com/apache/calcite/pull/2141#discussion_r485392343
##########
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:
I address this in the JIRA case. We never officially supported IN in
RexCall. We allowed it for limited cases only (e.g. RelToSql).
Calcite algebra isn't a free-for-all, where you can add your own built-in
operator and then holler when it is de-supported. If it was, people would end
up choking on each other's garbage.
This isn't 'drastic'. Most people aren't using this.
This isn't 'sudden'. For years I've been arguing in favor of expanding SQL
IN lists to ORs.
----------------------------------------------------------------
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
