raminqaf opened a new pull request, #29021:
URL: https://github.com/apache/flink/pull/29021
## What is the purpose of the change
`CAST(<string> AS FLOAT | DOUBLE)` only accepted the exact-case Java tokens
`NaN`, `Infinity` and `-Infinity`, because it delegates straight to
`Float.parseFloat` / `Double.parseDouble`. Common spellings such as `nan`,
`inf`, `infinity` and `-infinity` failed with a `NumberFormatException`
(`SELECT CAST('nan' AS FLOAT)`). This change makes the string-to-float/double
cast accept these special values case-insensitively, including the `inf`
abbreviation, bringing Flink in line with Spark and Snowflake.
## Brief change log
- `BinaryStringDataUtil.toFloat` / `toDouble` now normalize case-insensitive
and abbreviated special values before parsing.
- Recognized tokens: `nan` (unsigned), and `inf` / `infinity` with an
optional leading `+`/`-` sign. Any other input is passed through unchanged, so
ordinary numeric parsing and the `NumberFormatException` for invalid input are
preserved. A signed NaN (`-nan`) stays invalid.
## Verifying this change
This change added tests and can be verified as follows:
- Extended `BinaryStringDataTest.testToNumeric` with case-insensitive and
abbreviated `Infinity`, `-Infinity` and `NaN` inputs for both `toFloat` and
`toDouble`, plus assertions that ordinary numbers are unaffected and that a
signed NaN still throws.
## Compatibility, deprecation, alternatives
- Purely additive: inputs that used to parse still parse to the same value;
only inputs that previously errored now succeed.
- The token set and semantics match Spark's
`Cast.processFloatingPointSpecialLiterals` (`inf`/`+inf`/`infinity`/`+infinity`
→ +∞, `-inf`/`-infinity` → -∞, `nan` → NaN, signed NaN rejected) and
Snowflake's documented case-insensitive `nan`/`inf`/`infinity` handling.
- The VARIANT `PARSE_JSON` path is intentionally left rejecting these
tokens. That is consistent with Spark's `parse_json` and Snowflake's
`PARSE_JSON`, which both reject non-finite values as invalid JSON. The scalar
cast and JSON parsing are deliberately different paths.
## Does this pull request potentially affect one of the following parts:
- Dependencies (does it add or upgrade a dependency): no
- The public API, i.e., is any changed class annotated with
`@Public(Evolving)`: no
- The serializers: no
- The runtime per-record code paths (performance sensitive): yes,
`toFloat`/`toDouble` sit on the cast path. The added work is a `trim` (returns
the same instance when there is nothing to trim) and a few length-guarded
`equalsIgnoreCase` checks that short-circuit for ordinary numbers, so the
overhead is negligible.
- Anything that affects deployment or recovery: no
- The S3 file system connector: no
## Documentation
- Does this pull request introduce a new feature? no (behavior enhancement
to an existing cast)
- If yes, how is the feature documented? not applicable
---
##### Was generative AI tooling used to co-author this PR?
<!--
If generative AI tooling has been used in the process of authoring this PR,
please
change the checkbox below to `[X]` and replace the placeholder in the
"Generated-by"
line with the tool name and version. Otherwise remove the "Generated-by"
line.
See the ASF Generative Tooling Guidance for details:
https://www.apache.org/legal/generative-tooling.html
You are responsible for the quality and correctness of every change in this
PR
regardless of the tooling used. Low-effort AI-generated PRs will be closed.
See
AGENTS.md for the full guidance.
-->
- [X] Yes (please specify the tool below)
Generated-by: Opus 4.8
--
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]
