From e25d07c142cbff8e2bc88ef09e6cbb833bfb9e8f Mon Sep 17 00:00:00 2001
From: Wenchen Fan <wenchen@databricks.com>
Date: Tue, 19 May 2026 13:23:35 +0000
Subject: [PATCH] [SPARK-54119][SQL][FOLLOWUP] Format METRIC_VIEW DESCRIBE
 output distinctly from VIEW

### What changes were proposed in this pull request?

`CatalogTable.toJsonLinkedHashMap` emits the view-binding fields (`View
Schema Mode`, `View Catalog and Namespace`, `SQL Path`, `View Query
Output Columns`, `View Original Text`) for any `isViewLike` table. After
SPARK-54119 added `METRIC_VIEW` to `isViewLike`, those fields are now
also emitted for metric views. None of them apply: a metric view's
`viewText` is a YAML body (not a SQL query bound to a schema with
schema-evolution mode), so those rows are at best inert and at worst
misleading.

Narrow the view-binding block to `tableType == CatalogTableType.VIEW`,
and give `METRIC_VIEW` its own branch that emits just `View Text` plus a
`Language: YAML` tag so consumers can dispatch on the view_text format.

### Why are the changes needed?

To make `DESCRIBE TABLE EXTENDED AS JSON` output for `METRIC_VIEW`
accurately reflect its YAML nature, and avoid emitting SQL-view-specific
binding fields that have no meaning for a metric view.

This also makes the call site fork-friendly: forks that extend
`isViewLike` to include additional view-like kinds (materialized views,
streaming tables, etc.) no longer accidentally inherit the SQL-view
binding block for those kinds.

### Does this PR introduce _any_ user-facing change?

Yes. `DESCRIBE TABLE EXTENDED AS JSON` on a `METRIC_VIEW`:
- No longer emits `View Original Text`, `View Schema Mode`, `View
  Catalog and Namespace`, `SQL Path`, or `View Query Output Columns`.
- Now emits `Language: YAML`.
- Still emits `View Text` (the YAML body).

### How was this patch tested?

Compiles cleanly. Existing `MetricViewV2CatalogSuite` covers the v2-catalog
path via `DescribeV2ViewExec`, not this v1 `toJsonLinkedHashMap` path, so
it is unaffected.

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

No.
---
 .../apache/spark/sql/catalyst/catalog/interface.scala | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/catalog/interface.scala b/sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/catalog/interface.scala
index efd4bf621921e..6dda153985e56 100644
--- a/sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/catalog/interface.scala
+++ b/sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/catalog/interface.scala
@@ -675,7 +675,7 @@ case class CatalogTable(
     if (comment.isDefined) map += "Comment" -> JString(comment.get)
     if (collation.isDefined) map += "Collation" -> JString(collation.get)
 
-    if (isViewLike) {
+    if (tableType == CatalogTableType.VIEW) {
       if (viewText.isDefined) {
         map += "View Text" -> JString(viewText.get)
       }
@@ -710,6 +710,15 @@ case class CatalogTable(
       if (viewQueryOutputColumns != JNull) {
         map += "View Query Output Columns" -> viewQueryOutputColumns
       }
+    } else if (tableType == CatalogTableType.METRIC_VIEW) {
+      // METRIC_VIEW stores a YAML body in `viewText`, not a SQL query. The schema-binding
+      // fields used by plain VIEW (View Schema Mode, View Catalog and Namespace, SQL Path,
+      // View Query Output Columns) do not apply, so emit only `View Text` plus a `Language`
+      // tag so consumers can dispatch on the view_text format.
+      if (viewText.isDefined) {
+        map += "View Text" -> JString(viewText.get)
+      }
+      map += "Language" -> JString("YAML")
     }
     if (tableProperties != JNull) map += "Table Properties" -> tableProperties
     stats.foreach { s =>