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 type of 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 nano 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: 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
