[SPARK-57778][SQL] Handle Oracle JDBC objects that are not selectable as tables

[ivan-leventsov]

What changes were proposed in this pull request?

When using the built-in JDBC TableCatalog over Oracle, the driver's table listing returns objects that cannot be read as tables, for example a synonym that resolves to a PL/SQL procedure/function/package, or an invalid view. Probing such an object (tableExists via SELECT 1 FROM <obj> WHERE 1=0, or schema resolution via SELECT * FROM <obj> WHERE 1=0) raises ORA-04044 ("procedure, function, package, or type is not allowed here") or ORA-04063 ("... has errors"). These are currently unclassified, so tableExists throws instead of returning false, and table resolution surfaces a raw FAILED_JDBC error.

This PR adds a new JdbcDialect.isNotSelectableObjectException predicate (default false; OracleDialect recognizes ORA-04044/ORA-04063), kept separate from isObjectNotFoundException ("object does not exist"). With it:

• JdbcUtils.tableExists returns false for such objects instead of throwing;
• JDBCRDD.resolveTable throws a dedicated, clear error condition JDBC_OBJECT_NOT_SELECTABLE instead of a generic failure.

Why are the changes needed?

A schema legitimately contains synonyms/views that are not selectable as tables. Probing them should not surface a raw external-engine error or make existence checks throw; such objects should be reported as not a readable table.

Does this PR introduce any user-facing change?

Yes. For a JDBC catalog over Oracle:

• reading an object that is not selectable as a table now fails with the dedicated error condition JDBC_OBJECT_NOT_SELECTABLE (SQLSTATE 42000) instead of a raw FAILED_JDBC error;
• tableExists returns false for such an object instead of throwing.

How was this patch tested?

New cases in org.apache.spark.sql.jdbc.v2.OracleIntegrationSuite (docker-integration-tests), covering a synonym to a procedure, a synonym to a broken function (both ORA-04044), and an invalid view (ORA-04063). Each asserts that tableExists returns false and that reading the object fails with JDBC_OBJECT_NOT_SELECTABLE.

Was this patch authored or co-authored using generative AI tooling?

Yes, co-authored using Cursor (AI assistant).

[MaxGekk]

0 blocking, 1 non-blocking, 0 nits.
Clean Oracle error-classification extension that faithfully mirrors the existing isObjectNotFoundException predicate pattern (dialect default + Oracle override + tableExists/resolveTable wiring), kept deliberately separate so "not found" and "not selectable" stay distinct conditions.

Suggestions (1)

• JdbcDialects.scala:811: @Since("4.2.0") looks stale — current branch-4.x is 4.3.0, so a method added now first ships there — see inline.

Verification

• Predicate disjointness (the key correctness point): OracleDialect overrides isObjectNotFoundException to match only ORA-00942/ORA-39165, so it does NOT intercept ORA-04044/ORA-04063. The new isNotSelectableObjectException branch in resolveTable is therefore reachable (not dead), and it precedes the isSyntaxErrorBestEffort (42000) case so a 42000 SQLState can't divert it. tableExists returns false for these objects.
• Default false leaves non-Oracle dialects unaffected; the error condition is alphabetically placed with a matching <objectName> param and chained cause. Integration tests cover ORA-04044 (procedure + broken-function synonyms) and ORA-04063 (invalid view), asserting both tableExists=false and the dedicated error.

[MaxGekk]

dev/next_version_candidates.py reports the current branch-4.x at 4.3.0 (master 5.0.0), so a method added now first ships in 4.3.0 — 4.2.0 looks like it predates the recent version bump (the existing @Since("4.2.0") entries in this file are from the prior cycle).

Suggested change

	@Since("4.2.0")
	@Since("4.3.0")

[ivan-leventsov]

Thanks, fixed