stevenzwu commented on code in PR #11775:
URL: https://github.com/apache/iceberg/pull/11775#discussion_r2112903188
##########
api/src/main/java/org/apache/iceberg/expressions/Literals.java:
##########
@@ -300,8 +300,7 @@ public <T> Literal<T> to(Type type) {
case TIMESTAMP:
return (Literal<T>) new TimestampLiteral(value());
case TIMESTAMP_NANO:
- // assume micros and convert to nanos to match the behavior in the
timestamp case above
- return new TimestampLiteral(value()).to(type);
+ return (Literal<T>) new TimestampNanoLiteral(value());
Review Comment:
@ebyhr for the exception in your last comment with string literal, I assume
the partition column is a hour/day transformation on a timestamp_ns column? for
line 255 (`Projections` line), what is the literal for the `dataFilter`? Can
you add a unit test to reproduce and cover that scenario?
I understand it was done for compatibility with Spark. But I feel this
change is more intuitive than before. Since long literal value can't express
precision explicitly, it is more intuitive to assume the same precision as the
timestamp field type.
string literal can express different precisions in the string. I am
wondering if Spark will behave correctly if the filter value is a string
literal (with any precision). If it works correctly, can we ask Spark users not
to use long literal for timestamp_ns?
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
