This is an automated email from the ASF dual-hosted git repository.
HyukjinKwon pushed a commit to branch branch-4.x
in repository https://gitbox.apache.org/repos/asf/spark.git
The following commit(s) were added to refs/heads/branch-4.x by this push:
new 9ee428f86adb [SPARK-58864][SQL] Add remediation hint to
UNRECOGNIZED_SQL_TYPE error
9ee428f86adb is described below
commit 9ee428f86adb8943be98ace47f5f73f8d7526a71
Author: Ganesha S <[email protected]>
AuthorDate: Thu Aug 20 21:33:49 2026 +0900
[SPARK-58864][SQL] Add remediation hint to UNRECOGNIZED_SQL_TYPE error
### What changes were proposed in this pull request?
When the JDBC data source reads a column whose SQL type it cannot map to a
Catalyst type, it fails with the `UNRECOGNIZED_SQL_TYPE` error. This PR appends
a remediation hint to that error condition (in
common/utils/src/main/resources/error/error-conditions.json), pointing users at
the two supported ways to handle an unmapped type:
`Unrecognized SQL type - name: <typeName>, id: <jdbcType>.`
To read this column, map it explicitly with the `customSchema` option, or
register a custom `JdbcDialect` that handles this type. Only the message text
of the `UNRECOGNIZED_SQL_TYPE` condition changes; the error class, condition
name, SQL state (42704), and message parameters are untouched.
### Why are the changes needed?
The existing message states what failed but not what to do about it.
`UNRECOGNIZED_SQL_TYPE` is thrown only from the JDBC read path
(`JdbcUtils.getCatalystType`), and both remedies already exist: the
`customSchema` read option and a user-registered `JdbcDialect`. Surfacing them
lets users self-serve unmapped or vendor-specific types instead of reading
source or filing a support request.
### Does this PR introduce _any_ user-facing change?
Yes. The `UNRECOGNIZED_SQL_TYPE` error message now includes a second
sentence with remediation guidance. There is no change to the error class,
condition, SQL state, parameters, or behavior; only the human-readable text
changes.
### How was this patch tested?
No new tests are needed. Existing coverage (QueryExecutionErrorsSuite -
"`UNRECOGNIZED_SQL_TYPE: unrecognized SQL type DATALINK`", and JDBCSuite)
asserts on the error condition and its parameters via checkError, not on
literal message text, so it continues to pass. docs/sql-error-conditions.md is
generated from error-conditions.json at doc-build time, so no golden file needs
regenerating. The JSON was validated as well-formed.
### Was this patch authored or co-authored using generative AI tooling?
Generated-by: Claude Code (Opus 4.8)
Closes #58113 from ganeshashree/SPARK-58864.
Lead-authored-by: Ganesha S <[email protected]>
Co-authored-by: Ganesha S <[email protected]>
Signed-off-by: Hyukjin Kwon <[email protected]>
(cherry picked from commit db0a1ab82a0efb3a5a3db1e7f7e538f2af0535de)
Signed-off-by: Hyukjin Kwon <[email protected]>
---
common/utils/src/main/resources/error/error-conditions.json | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/common/utils/src/main/resources/error/error-conditions.json
b/common/utils/src/main/resources/error/error-conditions.json
index 71c050921ea6..c9df01610546 100644
--- a/common/utils/src/main/resources/error/error-conditions.json
+++ b/common/utils/src/main/resources/error/error-conditions.json
@@ -8304,7 +8304,8 @@
},
"UNRECOGNIZED_SQL_TYPE" : {
"message" : [
- "Unrecognized SQL type - name: <typeName>, id: <jdbcType>."
+ "Unrecognized SQL type - name: <typeName>, id: <jdbcType>.",
+ "To read this column, map it explicitly with the `customSchema` option,
or register a custom `JdbcDialect` that handles this type."
],
"sqlState" : "42704"
},
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
