SEZ9 commented on issue #12612:
URL: https://github.com/apache/seatunnel/issues/12612#issuecomment-5987005845

   Sorry for leaving this hanging, @SEPURI-SAI-KRISHNA — your sequencing 
argument is sound and I agree with it.
   
   **On the blocker:** you are right that the actionable item is on the 
committer side, not yours. Rebuilding `numberToInt` / `intFromExact` / 
`outOfIntRange` as a parallel `outOfLongRange` on `dev` just to avoid waiting 
would create exactly the duplication and conflict in front of 
`castAs(List<Object>)` that we would then ask you to undo. I will pick up 
#12605 at `c5b287cc5` for the committer-side review you need; I am not going to 
promise a merge date here, but it is on my list and you do not need to do 
anything further on this issue until it lands.
   
   **On the BIGINT scope you described:** that matches the previous review 
exactly, so no changes to the plan:
   
   - `BigDecimal` / `BigInteger` range-checked against 
`Long.MIN_VALUE`..`Long.MAX_VALUE` instead of relying on `longValue()` 
truncation
   - `NaN` and both infinities rejected for `Double` / `Float` rather than 
mapping to `0` / saturating
   - exact integral wrappers passed through unchanged
   - same truncate-then-range-check order as the INT fix, fraction handling 
untouched
   
   The test list (2^64+5, 2^64, `NaN`, 1e30 under both `CAST` failing and 
`TRY_CAST` returning null, plus the in-range `BigDecimal` → `BIGINT` control) 
is what I would want to see. One small request: also pin the exact 
`Long.MAX_VALUE` / `Long.MIN_VALUE` boundary values and one step beyond each, 
as you outlined in your first comment, so the bounds comparison is tested 
inclusively rather than only at far-out magnitudes.
   
   **Remaining asks once #12605 is merged:**
   1. Open the BIGINT PR on top of it, reusing the shared helpers rather than 
adding a long-specific duplicate, and reference this issue in the description.
   2. Include the test cases above in the same PR.
   
   Treating the `COALESCE` / `IFNULL` inference question as a separate issue is 
the right call; keep it out of this PR.
   
   <!-- streview-comment:1518 -->


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