manirajv06 commented on code in PR #13195:
URL: https://github.com/apache/iceberg/pull/13195#discussion_r2219796488
##########
api/src/main/java/org/apache/iceberg/expressions/VariantExpressionUtil.java:
##########
@@ -111,8 +113,19 @@ static <T> T castTo(VariantValue value, Type type) {
}
break;
- }
+ case TIMESTAMP:
+ case TIMESTAMP_NANO:
+ case TIME:
+ if (value.type() == PhysicalType.INT64) {
+ return (T) (Long) ((Number) value.asPrimitive().get()).longValue();
+ }
+ break;
+ case UUID:
Review Comment:
@aihuaxu Ok. While I tried to understand the UUID Literal, come to know that
Natural comparator is being used to compare the UUID's (UUID vs UUID). Since
there are 8 variants of UUID as per https://www.rfc-editor.org/rfc/rfc9562.txt,
and at least 4 of them has been supported in many widely used languages ( may
be few more ! ) , not really sure about the comparator being used as of now
would guarantee the correct results always as each variant requires a
customised way to compare the uuids. Please refer the comments in
https://bugs.openjdk.org/browse/JDK-8351406 also. Given these constraints, Is
it possible for us to do the right checks for UUID's? Is it safe to decide the
next steps based on this comparison?
On top of this, If we start reading UUID as String, CharSequences comparator
would be used for compare the strings, which would again cause more problems to
the results.
@RussellSpitzer @rdblue Please share your thoughts.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org
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
