LuciferYang opened a new pull request, #57034: URL: https://github.com/apache/spark/pull/57034
### What changes were proposed in this pull request? The data type parser converts integer type parameters (DECIMAL precision/scale, CHAR/VARCHAR length, TIME precision, GEOMETRY/GEOGRAPHY SRID) to `Int` with a raw `.toInt`. The grammar backs these with `INTEGER_VALUE : DIGIT+` (an unbounded digit run), so a value outside the 32-bit integer range overflows and throws a raw `java.lang.NumberFormatException` with no Spark error class. This guards the conversion on all three data-type parse paths so an out-of-range parameter raises a proper Spark error: - `DataTypeAstBuilder` (the ANTLR parser, used by SQL/CAST and `DataTypeParser.parseDataType`) - `DataType.nameToType` (the JSON path, `DataType.fromJson`) - `LegacyTypeStringParser` (the case-class string parser kept for Spark 1.1 and earlier Parquet compatibility) Routing: - DECIMAL precision reuses `DECIMAL_PRECISION_EXCEEDS_MAX_PRECISION` - TIME precision reuses `UNSUPPORTED_TIME_PRECISION` - GEOMETRY/GEOGRAPHY SRID reuses `ST_INVALID_SRID_VALUE` - CHAR/VARCHAR length and DECIMAL scale use a new `DATATYPE_PARAMETER_VALUE_OUT_OF_RANGE` error condition The `TIMESTAMP(p)` branch of the same parser already guarded this (raising `INVALID_TIMESTAMP_PRECISION`); the other type parameters are now brought in line. The unsupported-type branch additionally renders the raw token text instead of parsing it to `Int`, so an oversized parameter on an unsupported type (e.g. `FOO(9999999999)`) no longer leaks a `NumberFormatException` while building the `UNSUPPORTED_DATATYPE` message. ### Why are the changes needed? An out-of-`Int`-range type parameter surfaces a raw `java.lang.NumberFormatException` that is not a `SparkThrowable` -- it has no error condition and no SQLSTATE, so programmatic error handling (JDBC/Connect clients that read the condition/SQLSTATE) gets nothing, and callers that catch the parser's expected error surface may mistake it for an internal failure. For example: ```sql SELECT CAST(1 AS DECIMAL(9999999999, 2)); ``` throws: ``` java.lang.NumberFormatException: For input string: "9999999999" ``` The same happens via `StructType.fromDDL`, `DataType.fromJson`, `DataTypeParser.parseDataType`, and the legacy Parquet schema-string parser. This mirrors the fix in SPARK-56395 for the `NEAREST BY` num_results literal, which surfaced the same raw-`NumberFormatException` anti-pattern. ### Does this PR introduce _any_ user-facing change? Yes. An out-of-`Int`-range data type parameter now raises a Spark error with a proper error condition instead of a raw `NumberFormatException`. For example, `CAST(1 AS DECIMAL(9999999999, 2))` now raises `DECIMAL_PRECISION_EXCEEDS_MAX_PRECISION`, and `CAST(1 AS CHAR(9999999999))` raises the new `DATATYPE_PARAMETER_VALUE_OUT_OF_RANGE`. In-range values are unaffected. ### How was this patch tested? A new test in `DataTypeParserSuite` covering DECIMAL precision (scale-present and scale-absent), DECIMAL scale, CHAR/VARCHAR length (bare and `COLLATE`), TIME precision, GEOMETRY/GEOGRAPHY SRID, and an unsupported parameterized type, across the ANTLR, JSON, and legacy parse paths, plus a valid `Int.MaxValue` boundary case (`CHAR(2147483647)`). `catalyst/testOnly *DataTypeParserSuite` and `core/testOnly org.apache.spark.SparkThrowableSuite` pass. ### Was this patch authored or co-authored using generative AI tooling? Generated-by: Ducc -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
