Skip to content

[SPARK-58864][SQL] Add remediation hint to UNRECOGNIZED_SQL_TYPE error - #58113

Open
ganeshashree wants to merge 1 commit into
apache:masterfrom
ganeshashree:SPARK-58864
Open

[SPARK-58864][SQL] Add remediation hint to UNRECOGNIZED_SQL_TYPE error#58113
ganeshashree wants to merge 1 commit into
apache:masterfrom
ganeshashree:SPARK-58864

Conversation

@ganeshashree

Copy link
Copy Markdown
Contributor

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants