julianhyde commented on a change in pull request #2124:
URL: https://github.com/apache/calcite/pull/2124#discussion_r482251924
##########
File path: core/src/main/java/org/apache/calcite/rex/RexUtil.java
##########
@@ -2833,4 +2898,77 @@ public boolean anyContain(Iterable<? extends RexNode>
nodes) {
}
}
+ /** Converts a {@link Range} to a {@link RexNode} expression.
+ *
+ * @param <C> Value type */
+ private static class RangeToRex<C extends Comparable<C>>
+ implements RangeSets.Consumer<C> {
+ private final List<RexNode> list;
+ private final RexBuilder rexBuilder;
+ private final RelDataType type;
+ private final SqlTypeName typeName;
+ private final RexNode ref;
Review comment:
But that's the downstream project's problem, right? They sent the
algebra to Calcite. They get Calcite semantics.
I'm trying to create a simple abstraction here. You are making it more
complex. If it doesn't meet your requirements and is useless to you, turn it
off. But if we make the abstraction more complicated, it is now useless to
everyone.
In your example `f0 in ('foo ', 'bar', 'zoo')` if the types `CHAR(4)`,
`CHAR(3)` and `CHAR(3)` are not compatible in your type system, then this is
not a candidate for Sargs. I don't know the details, but you might find that in
PostgreSQL the types are actually `VARCHAR(4)`, `VARCHAR(3)` and `VARCHAR(3)`.
You figure it out. I'm not changing Sarg to accommodate.
----------------------------------------------------------------
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:
[email protected]
