[PR] [common] Support all TIMESTAMP precisions in the numeric string cast [paimon]

["LuciferYang (via GitHub)" <gi...@apache.org>]

LuciferYang opened a new pull request, #9622:
URL: https://github.com/apache/paimon/pull/9622

   ### Purpose
   
   close #9621
   
   `BinaryStringUtils.fromMillisToTimestamp` implemented the numeric-string to TIMESTAMP conversion as a `switch` over precisions 0, 3, 6 and 9, and threw `RuntimeException("Unsupported precision: N")` for everything else. `TimestampType` allows 0 through 9, so `CAST('1700000000' AS TIMESTAMP(4))` failed on a perfectly legal column type while the same string worked at precision 3.
   
   The four implemented cases are one formula sampled at four points: the value counts units of 10^-precision seconds, so a unit is 10^(3 - precision) milliseconds. Writing that formula covers all ten precisions, and it produces exactly what the four cases produced. At precision 6 the old code computed `epoch / 1000` and `(epoch % 1000) * 1000`; the formula gives `divisor = 1000`, `epoch / 1000` and `(epoch % 1000) * 1_000_000 / 1000`, which is the same value. Precisions 0, 3 and 9 line up the same way, so the four cases are gone rather than left beside the general path.
   
   The remainder is scaled before it is divided, so no digit the string carried is lost: `"170000000012"` at precision 8 gives 1700000 ms plus 120 ns. The existing negative-nanos correction below the branch is unchanged and still does the borrow, so `"-1700000001"` at precision 7 gives -170001 ms plus 999900 ns rather than a negative offset. Out-of-range precisions still throw the same message, now checked once against 0..9 instead of falling out of a `switch`.
   
   ### Tests
   
   `BinaryStringUtilsTest.testToTimestamp` gains nine rows: one hour expressed in each of the six previously rejected units, two cases where the remainder lands below a millisecond and has to come back as nanos-of-millisecond (precision 5 and precision 8), and a negative epoch at precision 7. `testInvalidPrecisions` drops 1, 2, 4, 5, 7 and 8, keeping 10 and -1.
   
   Against the unfixed code nine of those rows error with `RuntimeException: Unsupported precision`.
   
   `mvn -pl paimon-common -Dtest=BinaryStringUtilsTest test` on JDK 8: 31 tests, 0 failures. `spotless:check` and `checkstyle:check` on paimon-common are clean.
   


-- 
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-unsubscribe@paimon.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] [common] Support all TIMESTAMP precisions in the numeric string cast [paimon]

["JingsongLi (via GitHub)" <gi...@apache.org>]

JingsongLi closed pull request #9622: [common] Support all TIMESTAMP precisions in the numeric string cast
URL: https://github.com/apache/paimon/pull/9622


-- 
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-unsubscribe@paimon.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] [common] Support all TIMESTAMP precisions in the numeric string cast [paimon]

["JingsongLi (via GitHub)" <gi...@apache.org>]

JingsongLi commented on PR #9622:
URL: https://github.com/apache/paimon/pull/9622#issuecomment-5613745249

   Closing the current proposal because it introduces six additional numeric epoch-unit conventions without establishing a user requirement for those semantics. A valid TIMESTAMP precision of 0..9 does not by itself establish how an integer string should be interpreted. The existing numeric conversion deliberately accepts seconds/milliseconds/microseconds/nanoseconds (0/3/6/9), and testInvalidPrecisions has explicitly rejected 1/2/4/5/7/8 since #5710; formatted timestamp strings already take the parsing path at those precisions.
   
   The default-value path is real, but the new tests prove the chosen power-of-ten formula rather than justify interpreting input in deciseconds, centiseconds, 100-microsecond, 10-microsecond, 100-nanosecond and 10-nanosecond units. Please reopen with a concrete producer/ingestion scenario, an agreed input-unit contract and an end-to-end default-value or ingestion test that verifies the intended instant.


-- 
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-unsubscribe@paimon.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org