bvolpato commented on code in PR #39592:
URL: https://github.com/apache/beam/pull/39592#discussion_r3709588587


##########
sdks/java/extensions/sql/src/main/java/org/apache/beam/sdk/extensions/sql/impl/rel/BeamCalcRel.java:
##########
@@ -684,6 +699,12 @@ private static Expression toCalciteValue(
                     Expressions.multiply(dateValue, 
Expressions.constant(MILLIS_PER_DAY)),
                     Expressions.divide(timeValue, 
Expressions.constant(NANOS_PER_MILLISECOND)));
             return nullOr(value, returnValue);
+          } else if 
(org.apache.beam.sdk.schemas.logicaltypes.Timestamp.IDENTIFIER.equals(
+              identifier)) {
+            return nullOr(
+                value,
+                Expressions.call(
+                    Expressions.convert_(value, java.time.Instant.class), 
"toEpochMilli"));

Review Comment:
    can contain sub-millisecond values, but this conversion goes through epoch 
milliseconds. I reproduced this with :  comes back as . Could we preserve 
microsecond precision here, or reject values that Calcite cannot represent 
without loss?



##########
sdks/java/extensions/sql/src/main/java/org/apache/beam/sdk/extensions/sql/impl/rel/BeamCalcRel.java:
##########
@@ -684,6 +699,12 @@ private static Expression toCalciteValue(
                     Expressions.multiply(dateValue, 
Expressions.constant(MILLIS_PER_DAY)),
                     Expressions.divide(timeValue, 
Expressions.constant(NANOS_PER_MILLISECOND)));
             return nullOr(value, returnValue);
+          } else if 
(org.apache.beam.sdk.schemas.logicaltypes.Timestamp.IDENTIFIER.equals(
+              identifier)) {
+            return nullOr(
+                value,
+                Expressions.call(
+                    Expressions.convert_(value, java.time.Instant.class), 
"toEpochMilli"));

Review Comment:
   `Timestamp.MICROS` can contain sub-millisecond values, but this conversion 
goes through epoch milliseconds. I reproduced this with `SELECT * FROM 
PCOLLECTION`: `2025-07-31T20:17:40.123456Z` comes back as 
`2025-07-31T20:17:40.123Z`. Could we preserve microsecond precision here, or 
reject values that Calcite cannot represent without loss?



-- 
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]

Reply via email to