zhangshenghang opened a new pull request, #11523:
URL: https://github.com/apache/seatunnel/pull/11523
## Purpose of the change
Fixes #10198.
Syncing MySQL `FLOAT` columns (e.g. GPS coordinates) through the SQL
transform silently loses precision: a source value of `126.752251`
(`float(10,6)`) lands in a PostgreSQL `numeric(10,6)` column as `126.752250`.
## Root cause
MySQL stores `FLOAT` as an IEEE-754 binary value; the value behind
`126.752251` is exactly `126.75225067138671875`. MySQL's own `CAST(col AS
DECIMAL(20,10))` converts that **exact binary value** and returns
`126.7522506714` (which rounds to `126.752251` at 6 digits).
The Zeta SQL function `SystemFunction.castAs` did `new
BigDecimal(v1.toString())`. `Float.toString()` returns the shortest round-trip
string `"126.75225"`, discarding the hidden binary digits **before** scaling,
so SeaTunnel produced `126.7522500000` — off by one ULP at 6 digits, exactly
the discrepancy reported in the issue.
## Changes
- **`SystemFunction.castAs` (DECIMAL branch)**
- `Float`/`Double` inputs are now converted with `new
BigDecimal(floatValue/doubleValue)`, i.e. from the exact binary value, matching
database CAST semantics.
- `BigDecimal` inputs pass through without re-parsing.
- All other input types keep the previous string-based conversion, so
behavior is unchanged for them.
- **`SystemFunctionTest#testCastAsDecimalKeepsExactBinaryValueOfFloats`**
(new)
- `CAST(126.752251f AS DECIMAL(20,10)) == 126.7522506714` (equals MySQL's
result; previously `126.7522500000`)
- `CAST(126.752251f AS DECIMAL(10,6)) == 126.752251` (previously
`126.752250`)
- `CAST(44.916103d AS DECIMAL(20,10)) == 44.9161030000`
- BigDecimal pass-through case.
## Verification
- `./mvnw -pl seatunnel-transforms-v2 test` — full module test suite passes
(including `SystemFunctionTest`, `CastFunctionTest`, `CastFunctionTypeTest`).
## Notes
- The rounding mode (`CEILING`) is intentionally left untouched to keep this
change minimal; this PR only fixes the lossy string round-trip reported in the
issue.
--
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]
