SEZ9 commented on issue #12571: URL: https://github.com/apache/seatunnel/issues/12571#issuecomment-5924010986
Thanks for the detailed, reproducible report and result table. The inconsistency is clear: for `INT`, a string source goes through `Integer.parseInt`, which reports overflow, while a numeric source goes through `((Number) v1).intValue()`, which truncates silently. A consistent fix is to range-check the numeric narrowing path in `SystemFunction.castAs` for `INT` (and `SMALLINT`/`TINYINT` where the planner accepts the source) so numeric sources fail the same way string sources do, and `TRY_CAST` then yields null in both cases. The `FLOAT` cases returning `Infinity` are worth tracking separately: both paths end at `Float.parseFloat`, which returns `Infinity` by design, so whether out-of-range float casts should error or keep returning `Infinity` is its own compatibility decision and should not be bundled into the first change. The plan-time rejections (`Unsupported CAST FROM INT AS type: SMALLINT`) for `INT -> SMALLINT` and `INT -> TINYINT` look like a gap rather than overflow protection, since `CastFunction.getCastType` accepts the same targets from `STRING`. If you add those narrowing paths, please add them with the same range checks. Since you have already offered a PR, option 1 is the direction to take. Unit tests covering each row of your table, including the exact minimum and maximum boundary for each integral target, would be a good starting point. <!-- streview-comment:1446 --> -- 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]
