LuciferYang opened a new issue, #9621:
URL: https://github.com/apache/paimon/issues/9621

   ### Search before asking
   
   - [x] I searched in the [issues](https://github.com/apache/paimon/issues) 
and found nothing similar.
   
   ### Paimon version
   
   master, `475be566f` (2.1-SNAPSHOT).
   
   ### Compute Engine
   
   Any. The cast runs in `BinaryStringUtils`, reached from column default 
values, partition value parsing, filter literals pushed down from Flink and 
Spark, CDC ingestion and the Hive output format.
   
   ### Minimal reproduce step
   
   Cast a numeric string to a TIMESTAMP whose precision is not 0, 3, 6 or 9:
   
   ```java
   BinaryStringUtils.toTimestamp(BinaryString.fromString("1700000000"), 4);
   // java.lang.RuntimeException: Unsupported precision: 4
   ```
   
   `TimestampType` accepts 0 through 9 (`MIN_PRECISION` 0, `MAX_PRECISION` 9) 
and validates nothing else, so `TIMESTAMP(4)` is a legal column type. A table 
with such a column reaches this through, for example, a default value:
   
   ```sql
   CREATE TABLE t (id INT, ts TIMESTAMP(4)) WITH ('fields.ts.default-value' = 
'1700000000');
   ```
   
   The same string at precision 3, 6 or 9 converts fine, and a date-shaped 
string like `'2026-01-15 10:00:00'` converts fine at precision 4 as well, 
because that goes down a different path. It is only the numeric fast path that 
rejects the precision:
   
   ```java
   switch (precision) {
       case 0: ...
       case 3: ...
       case 6: ...
       case 9: ...
       default:
           throw new RuntimeException("Unsupported precision: " + precision);
   }
   ```
   
   ### What doesn't meet your expectations?
   
   Six of the ten legal precisions cannot take a numeric string. There is 
nothing special about them: the value counts units of 10^-precision seconds, so 
one unit is 10^(3 - precision) milliseconds, and the four implemented cases are 
just that formula at four points. Precisions 1, 2, 4, 5, 7 and 8 are the same 
arithmetic with a different power of ten.
   
   ### Anything else?
   
   Nothing in the method guards against overflow for the low precisions (`epoch 
* 1000` at precision 0 wraps for a large enough string), which is pre-existing 
and unrelated to which precisions are accepted.
   
   ### Are you willing to submit a PR?
   
   - [x] I'm willing to submit a PR!
   


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