[SPARK-33902][SQL][FOLLOWUP] Add createTableLike delegation to DelegatingCatalogExtension

[sarutak]

What changes were proposed in this pull request?

This PR adds the missing createTableLike(Identifier, TableInfo, Table) delegation to DelegatingCatalogExtension.

Why are the changes needed?

DelegatingCatalogExtension is designed to delegate all catalog operations to the underlying session catalog, so that subclasses (e.g., Delta's DeltaCatalog, Hudi's HoodieCatalog) only need to override methods where they want custom logic.

createTableLike was added to TableCatalog in SPARK-33902 but the corresponding delegation in DelegatingCatalogExtension was not added. Without it, connectors extending DelegatingCatalogExtension that do not explicitly override createTableLike will hit the default UnsupportedOperationException, even if the underlying delegate catalog supports the operation.

This is the same class of issue that was fixed in SPARK-42398 (#40369), where the createTable(Column[]) overload was added to TableCatalog but the delegation in DelegatingCatalogExtension was missed.

Note: createTable(Identifier, TableInfo) (added in 4.1.0) is intentionally not delegated here. Its default implementation in TableCatalog falls back to createTable(ident, columns, partitions, properties), which is already delegated. Explicitly delegating createTable(TableInfo) would bypass subclass overrides of createTable(Column[]).

Does this PR introduce any user-facing change?

No. CREATE TABLE LIKE for DSv2 is a new feature in Spark 4.2 and it's not been released yet.

How was this patch tested?

GA.

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

Generated-by: Claude (via Kiro CLI, auto model selection)

[dongjoon-hyun]

+1, LGTM.

cc @viirya from the original PR.

• #54809

Also, cc @peter-toth .

[viirya]

The fix itself looks correct and consistent with the surrounding delegations, and the precedent in SPARK-42398 is a good fit

One nit on the motivation: I checked and the actual delegate that gets injected into DelegatingCatalogExtension subclasses — V2SessionCatalog — does not implement createTableLike either. So the phrase "even if the underlying delegate catalog supports the operation" in the PR description is counterfactual today: with or without this patch, a subclass that does not override createTableLike will still get UnsupportedOperationException, just thrown from a different layer.

Going one step further, the routing in ResolveSessionCatalog (:319-328) actually short-circuits CREATE TABLE ... LIKE to the v1 CreateTableLikeCommand whenever the target resolves through the session catalog — and supportsV1Command (:981-985) explicitly counts CatalogExtension instances as v1-compatible. That means even for DelegatingCatalogExtension subclasses, the real CREATE TABLE LIKE flow against the session catalog never reaches v2 TableCatalog.createTableLike at all; it's handled by the v1 path. So this delegation doesn't unblock any user-visible case today.

The change is still worth doing — it keeps the "all catalog functions are delegated" contract of DelegatingCatalogExtension intact, mirroring SPARK-42398, so that subclasses can rely on the base class for any future delegate that does implement createTableLike, or call super.createTableLike(...) from their own override. Could you reword the description to reflect that this is a contract-consistency fix rather than unblocking an already-supported operation?

[dongjoon-hyun]

Let me merge this because Apache Spark 4.2.0 RC1 is planned this week. Otherwise, this should have a new JIRA issue instead of FOLLOWUP.

• [FYI] Spark 4.2.0 RC1 planned for May 20

[dongjoon-hyun]

Merged to master/4.x/4.2.