stevenzwu commented on code in PR #11775:
URL: https://github.com/apache/iceberg/pull/11775#discussion_r2162151134
##########
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:
sure. But at least the broken behavior using string literal with identity
partition transformation on timestamp_ns column has minimal/no impact in
practice, since it is not really a viable setup with production workload. the
string literal problem can be tracked separately than the long literal issue.
Come back to this PR/issue, we need to decide on what to do with long
literal for timestamp_ns. there are two options (1) derive/imply the precision
(micro or nano) based the timestamp column type, which is the current approach
this PR (2) always assume micro second precision for consistent interpretation
behavior regardless of column timestamp precision, which is the current
behavior and where Ryan coming from.
It seems that there is no consensus on adopting the behavior change of
option 1. To move forward without changing current behavior and causing
confusions to users, we can adopt these two steps
1) for the immediate step, fail the long literal (assumed micro precision)
to nano ts with an explicit and more friendly error msg (suggested by Russel).
For now, users should use the string literal with hour/day/week/month
transformation on timestamp_nano partition column.
2) for the longer term, we can expose public methods for engines/clients to
construct `TimestampLiteralNano` directly. Then long literal can used correctly
with timestamp nano type, e.g. `ts < timestamp_nano(1230219000123123)`
--
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
