SEPURI-SAI-KRISHNA opened a new issue, #12612:
URL: https://github.com/apache/seatunnel/issues/12612

   ### Search before asking
   
   - [X] I had searched in the 
[issues](https://github.com/apache/seatunnel/issues?q=is%3Aissue+label%3A%22bug%22)
 and found no similar issues.
   
   ### What happened
   
   `CAST(... AS BIGINT)` silently wraps a numeric value that `BIGINT` cannot 
represent, in the same way `CAST(... AS INT)` did before #12605. Measured on 
`dev` by running the conversion:
   
   | input | `CAST(... AS BIGINT)` |
   | --- | --- |
   | `BigDecimal` `18446744073709551621` (2^64+5) | `5` |
   | `BigDecimal` `18446744073709551616` (2^64) | `0` |
   | `Double` `NaN` | `0` |
   | `Double` `1e30` | `9223372036854775807` |
   
   `SystemFunction.castAs` converts the `BIGINT` | `LONG` numeric branch with 
`((Number) v1).longValue()`. That keeps only the low-order 64 bits of a 
`BigDecimal` or `BigInteger`, maps `NaN` to zero, and saturates an out-of-range 
`Double`. None of it is reported, so the row is written with a wrong number.
   
   `TRY_CAST` cannot help either, because nothing underneath signals a failure 
for it to turn into `NULL`.
   
   A `DECIMAL` or `DOUBLE` source reaches the `BIGINT` target through 
`COALESCE` and `IFNULL`, whose result type `ZetaSQLType` infers from the first 
non-null argument rather than the widest, so the other arguments are not 
constrained.
   
   ### SeaTunnel Version
   
   `dev` (3.0.0-SNAPSHOT).
   
   ### What you expected to happen
   
   The conversion fails when the value cannot be represented, so `TRY_CAST` can 
return `NULL` for it, consistent with what #12605 does for `INT`.
   
   ### Context
   
   Split out of #12571 on review. The agreed scope there was `TINYINT`, 
`SMALLINT` and `INT`, and @DanielLeens confirmed on #12605 that `BIGINT` 
belongs in its own issue and PR rather than widening that change.
   
   The fix shape is the same per-family range check #12605 added for `INT`: 
check `BigDecimal` and `BigInteger` against the long bounds before narrowing, 
reject `NaN` and the infinities for `Double` and `Float`, and leave the exact 
integral wrappers alone.
   
   ### Are you willing to submit PR?
   
   - [X] Yes I am willing to submit a PR.
   
   ### Code of Conduct
   
   - [X] I agree to follow this project's [Code of 
Conduct](https://www.apache.org/foundation/policies/conduct)
   


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