SEPURI-SAI-KRISHNA commented on issue #12612: URL: https://github.com/apache/seatunnel/issues/12612#issuecomment-5981369968
Thanks @SEZ9. Agreed on all three points, and the PR is coming. One note on timing, since it affects #12605 rather than this issue. **The scope you describe is exactly what I plan to write.** Per-family range check on the BIGINT/LONG branch, `BigDecimal` and `BigInteger` compared against `Long.MIN_VALUE`..`Long.MAX_VALUE`, `NaN` and both infinities rejected for `Double`/`Float`, exact integral wrappers passed through unchanged. Unit tests for 2^64+5, 2^64, NaN and 1e30 under both `CAST` (fails) and `TRY_CAST` (returns null), plus an in-range `BigDecimal` to `BIGINT` case pinned as a control so the fix cannot silently tighten something that works today. **It is sequenced behind #12605, as I noted above before your review.** That PR adds the three helpers this fix reuses: `numberToInt`, `intFromExact` and `outOfIntRange`. They do not exist on `dev`, so writing the BIGINT version today would mean adding a near-duplicate `outOfLongRange` that you would reasonably ask to be unified. #12605 also inserts its helper block immediately before `castAs(List<Object>)`, which is precisely where the BIGINT helper belongs, so two branches would conflict in that one file. **So the thing actually blocking the PR you asked for is #12605 being merged.** Its current state: - head `c5b287cc5`, Build run `37129367555` finished `success` on the first attempt, no reruns needed - approved by @DanielLeens on 2026-10-03 - `mergeStateStatus: BLOCKED`, `reviewDecision: REVIEW_REQUIRED` So it needs a committer with write access to approve or merge. Once it lands I will open the BIGINT PR on top of it the same day, reusing those helpers with the long bounds and the same truncate-then-range-check order. **On COALESCE and IFNULL, yes, a separate issue is the right call.** I checked the current behaviour on `dev` rather than relying on the sentence in the issue body: `ZetaSQLType:474-486` handles `IFNULL` and `COALESCE` by walking the arguments and returning the type of the first one that is neither a `NullValue` nor `VOID_TYPE`. So `COALESCE(int_col, bigint_col)` infers `INT` and the second argument is never widened. That is a type-inference question rather than a narrowing-on-cast question, so it does not belong in this PR. I will open it separately with a reproduction, and it is independent of #12605 so it does not have to wait. -- 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]
