MaxGekk commented on code in PR #56622:
URL: https://github.com/apache/spark/pull/56622#discussion_r3447604380
##########
sql/catalyst/src/test/scala/org/apache/spark/sql/catalyst/parser/ExpressionParserSuite.scala:
##########
@@ -1376,6 +1388,17 @@ class ExpressionParserSuite extends AnalysisTest {
fragment = "time '12-13.14'",
start = 0,
stop = 14))
+
+ // More than 9 fractional-second digits is rejected.
Review Comment:
Intentional, and it mirrors how TIMESTAMP literals vs casts already behave
in this same `AstBuilder` path:
- A **literal**'s fractional precision *is* its digit count (ANSI ISO/IEC
9075-2, Subclause 5.3, Syntax Rule 26), so `TIME '...1234567890'` declares a
`TIME(10)` literal, which is out of range -> `INVALID_TIME_LITERAL_PRECISION`.
This is the same rule that makes `TIMESTAMP_NTZ '...1234567890'` raise
`INVALID_TIMESTAMP_LITERAL_PRECISION`.
- A **cast** targets an explicit `TIME(p)` whose resolution is capped at
nanoseconds; the 10th digit is sub-nanosecond and simply cannot be represented,
so the shared `parseTimestampString` drops digits beyond the 9th (general
string->datetime parse leniency). `CAST('...1234567890' AS TIMESTAMP_NTZ(9))`
behaves the same way.
So the split is by design: the literal path validates the ANSI literal
precision, while the cast path inherits the parser's truncation of
unrepresentable sub-nanosecond digits. I can add a short cast test asserting
the >9 truncation to make the intent explicit if you'd like.
--
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]
