SEPURI-SAI-KRISHNA commented on issue #12571: URL: https://github.com/apache/seatunnel/issues/12571#issuecomment-5977425698
Both still present at head `c5b287cc5`, confirmed by reading the blobs at that commit rather than from memory. **COALESCE / IFNULL regression test.** `ZetaSQLEngineTest.testCoalesceAndIfnullAlsoRejectAnOutOfRangeNarrowing`, which covers both `coalesce(c_int, c_bigint)` and `ifnull(c_int, c_bigint)`. Each one asserts a `TransformException` for the overflowing value `3000000000L`, and then re-runs the same SQL on a fresh engine with an in-range value to pin that the non-overflow path still returns normally. The comment above it records why the target is `INT`: `ZetaSQLType` infers the result type from the first non-null argument rather than the widest one, so `COALESCE(int, bigint)` targets `INT` and reached the same `castAs` boundary. The `-1294967296` value you referenced is the pre-change truncation of `3000000000`, so the test pins the same case by asserting the error instead of that silently wrapped result. **Incompatible-changes entry.** Present on both pages, `docs/en/introduction/concepts/incompatible-changes.md` and the zh equivalent, under "Zeta SQL Transform: CAST to INT rejects out-of-range numeric values". It carries the behaviour change, the reason, the migration guidance to use `TRY_CAST`, and the `BIGINT` gap tracked as #12612. So the range check, the COALESCE regression test and the docs entry all land together in this PR as you asked. -- 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]
