jackye1995 commented on a change in pull request #1747:
URL: https://github.com/apache/iceberg/pull/1747#discussion_r529016643
##########
File path: api/src/main/java/org/apache/iceberg/expressions/Expressions.java
##########
@@ -123,6 +123,22 @@ public static Expression not(Expression child) {
return new UnboundPredicate<>(Expression.Operation.NOT_NULL, expr);
}
+ public static <T> UnboundPredicate<T> isNaN(String name) {
+ return new UnboundPredicate<>(Expression.Operation.IS_NAN, ref(name));
+ }
+
+ public static <T> UnboundPredicate<T> isNaN(UnboundTerm<T> expr) {
+ return new UnboundPredicate<>(Expression.Operation.IS_NAN, expr);
+ }
+
+ public static <T> UnboundPredicate<T> notNaN(String name) {
+ return new UnboundPredicate<>(Expression.Operation.NOT_NAN, ref(name));
+ }
+
+ public static <T> UnboundPredicate<T> notNaN(UnboundTerm<T> expr) {
+ return new UnboundPredicate<>(Expression.Operation.NOT_NAN, expr);
+ }
Review comment:
Okay so it's what I thought, just a bit confused by the notation.
So for `eq`, what is the benefit of doing it in `UnboundedPredicate` versus
just rewriting it in the `Expressions`?
For `in`, I think it is a more complex question.We need to figure out:
1. should syntax like `in(1,2,NaN)` be supported, given it can be written as
`is_nan or in(1,2)` on client side
2. if so, `Expressions.in` should return `Expression` as you said, which
looks fine to me because the only caller `SparkFilters.convert` also returns an
`Expression` in the end.
3. maybe we should tackle this in another PR to keep changes concise.
----------------------------------------------------------------
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
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org
For additional commands, e-mail: issues-h...@iceberg.apache.org
