DanielLeens commented on issue #12571: URL: https://github.com/apache/seatunnel/issues/12571#issuecomment-5917741465
Classification: E / Transform-V2 numeric conversion compatibility. I checked current `dev` (`53733a112c9e935c5d97f7f24be249caa43b4fd5`). `CastFunction` explicitly admits `BIGINT` to `INT`, while `SystemFunction.castAs` reaches `Number.intValue()` for numeric inputs and `Integer.parseInt()` for strings. That explains the observed inconsistency and means an out-of-range integral value can silently change before `TRY_CAST` has a failure to convert to null. The direction is to make the integral narrowing path fail on out-of-range numeric input, matching the existing string behavior. Keep the first change focused on integral targets (`TINYINT`, `SMALLINT`, and `INT`) and the source types currently accepted by the planner. It must cover both `CAST` failure and `TRY_CAST` returning null, with exact boundary tests at each target minimum and maximum. Do not bundle floating-point `Infinity` semantics into this PR; that is a separate compatibility decision. This is a behavior change for jobs that currently rely on wraparound, so document it in both language references and keep the implementation at the shared cast boundary rather than connector-specific code. Please post the focused test matrix before opening the PR so reviewers can confirm that valid in-range conversions and existing widening behavior remain unchanged. -- 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]
