[SPARK-59778][SQL] Add display-only properties to the Table API - #59036

This also changes the public API spark.catalog.getTableProperties, because classic.Catalog.getTableProperties is implemented by executing a ShowTableProperties plan. PySpark and Spark Connect (SparkConnectPlanner.transformGetTableProperties) go through the same path. The API was released in 4.2.0 and is documented as "Returns all table properties as a map (same as SHOW TBLPROPERTIES)".

Take a connector whose displayProperties() returns properties() + {"catalog-label" -> "catalog-value"}:

• spark.catalog.getTableProperties("cat.ns.t") contains catalog-label.
• spark.catalog.getCreateTableString("cat.ns.t") doesn't.

User code that copies table properties via getTableProperties(src) into CREATE TABLE ... TBLPROPERTIES, ALTER TABLE ... SET TBLPROPERTIES or DataFrameWriterV2.tableProperty would then persist the transient label on the target table. That is the leak this PR prevents for SHOW CREATE TABLE. The existing getTableProperties tests only use V1 tables, so they don't cover this.

Could you either keep getTableProperties on properties(), or document this behavior change in the PR description and the API doc, with a test?

Kept getTableProperties() consistent with SHOW TBLPROPERTIES, including the additional display-only entries. The Scala and Python API docs and PR description now explain that these entries may be transient and unsuitable for copying into DDL, and point to getCreateTableString(). Added a V2 test in org.apache.spark.sql.internal.CatalogSuite covering the returned properties, unchanged table type/description, and exclusion of the display-only entry from generated DDL. Existing connectors retain their behavior because the new method defaults to an empty map.

This switches not only the free-form Table Properties list but also the Type row (EXTERNAL/MANAGED via PROP_EXTERNAL) and the reserved-property rows (Comment, Collation, Location, Provider, Owner, ...) to displayProperties(). ShowTablesExtendedExec does the same.

However, the new Javadoc doesn't say that displayProperties() must be a superset of properties(). Suppose a connector takes "display-only properties" literally and returns only its labels, e.g. Map.of("label", "x"). For an external table:

• DESCRIBE TABLE EXTENDED and SHOW TABLE EXTENDED show Type MANAGED and drop the Location/Provider/Owner rows.
• SHOW TBLPROPERTIES t ('k') returns "does not have property: k" for a persisted key k.

Meanwhile SHOW CREATE TABLE and spark.catalog.getTable(...).tableType/description still read properties(), so they disagree. Also, a display key named like a reserved key (owner, location, external, ...) silently overrides that row. Because the check is containsKey(PROP_EXTERNAL), even external=false shows EXTERNAL.

Could we keep Type and the reserved rows on table.properties() and use displayProperties() only for the Table Properties list? If not, please document the superset and reserved-key contract in the Javadoc.

Changed both commands so Type and all reserved metadata rows continue to read properties(). The shared CatalogV2Util.tablePropertiesForDisplay() helper merges the additional entries with properties() (existing values win), then removes reserved keys from the free-form property list. The Javadoc now defines that contract, and the command tests cover managed/external tables and conflicting reserved display keys.

FYI, the session catalog never reaches this exec. For spark_catalog (builtin, or a CatalogExtension such as Delta/Iceberg-style session catalogs), ResolveSessionCatalog always rewrites ShowTablesExtended(ResolvedV1Database(db), ...) to the v1 ShowTablesCommand; there is no useV1Command guard. That command prints CatalogTable.simpleString and never calls loadTable() or displayProperties().

DESCRIBE TABLE EXTENDED and SHOW TBLPROPERTIES, by contrast, fall back to v1 only for V1Table. When the extension returns its own Table implementation, those two use the v2 execs. So for the same session-catalog table, the display-only keys appear in DESCRIBE TABLE EXTENDED and SHOW TBLPROPERTIES but not in SHOW TABLE EXTENDED.

The PR description says the metadata appears in SHOW TABLE EXTENDED with no conditions. Could you document the scope, or add a session-catalog test that pins the current behavior?

Documented this scope in the PR description. The new properties are used only by the V2 table execution paths. SHOW TABLE EXTENDED for spark_catalog, including session-catalog extensions, still uses the V1 command. The description also calls out that DESCRIBE TABLE EXTENDED and SHOW TBLPROPERTIES can use the new API when an extension returns a V2 table.

Minor: the display commands now call this new default method instead of properties(). Under Mockito's default answer (RETURNS_DEFAULTS), a mock doesn't run default methods, so a Table mock returns an empty HashMap here. Take a mock that only stubs when(t.properties()).thenReturn(Map("external" -> "true", "k" -> "v").asJava):

• DescribeTableExec now gives Type MANAGED and Table Properties [].
• SHOW TBLPROPERTIES returns 0 rows.

Spark's own tests don't do this. Downstream connector tests may change without warning, though, and would need thenCallRealMethod(). A note in the PR description may be worth it.

The additive API addresses this: an empty display map now contributes no extra entries, while Spark still reads properties(). Added a CatalogV2UtilSuite regression test with a Mockito mock that stubs only properties() and leaves displayProperties() unstubbed. No thenCallRealMethod() is needed for the existing properties to remain visible; the PR description also notes this.

Design question: this models display-only metadata as a second full property map that defaults to properties().

• An implementation has to copy the persisted properties just to add one label, as the test does with new util.HashMap[String, String](table.properties).
• There are two sources of truth for the same keys. A cached display map can go stale after ALTER TABLE ... SET TBLPROPERTIES while SHOW CREATE TABLE shows the new value.

Have you considered an additive form instead? For example, a map of catalog-owned extras that defaults to empty, which Spark merges as properties() ++ extras (persisted/reserved keys win) or renders as separate rows. That matches existing additive patterns such as SupportsMetadataColumns and the Statistics/Metadata Columns/Constraints sections of DESCRIBE, and it removes the superset-contract question. Since this is a new public API (@since 4.4.0), it would be good to settle the shape before it is released.

Adopted the additive form. displayProperties() now returns only extra entries and defaults to an empty map. Spark merges them with the current properties(), gives existing values precedence, and filters reserved keys in one shared helper. The SHOW TBLPROPERTIES test includes a colliding key and verifies that an ALTER TABLE ... SET TBLPROPERTIES update is reflected while the additional entry is preserved.

This per-instance state doesn't survive when the in-memory test infra copies or rebuilds a table:

• InMemoryTable.copy() and the other copy() implementations only call setVersionAndValidatedVersionFrom.
• InMemoryTableCatalog.alterTable rebuilds the table via newInMemoryTable.
• pinTable copies the table.

setDisplayProperties is then silently lost and displayProperties() falls back to properties. That happens with:

• copyOnLoad=true catalogs, e.g. CachedTableSuite and DataSourceV2DataFrameSuite.
• row_level_op_catalog, which always returns rlot.copy() and is registered in the same v2 CommandSuiteBase.
• Any ALTER TABLE.

The new test passes only because test_catalog returns the live instance. Could you document this limitation, or store only the extra entries and propagate them on copy?

The fixture now stores only the additional entries and copies them defensively. Renamed the shared state-copy helper to copyTableStateFrom() and updated its callers to propagate display metadata alongside version state; table reconstruction during ALTER TABLE also preserves it. Added tests for copyOnLoad, the row-level operation catalog, pinning, and alteration, including checks that pinned properties retain their original values while the current table reflects the update.

nit: this test checks SHOW TBLPROPERTIES, SHOW TABLE EXTENDED and SHOW CREATE TABLE inside the DESCRIBE TABLE suite ("contains tests for the DESCRIBE TABLE command"). It runs as "DESCRIBE TABLE using V2 catalog V2 command: ...", so people working on ShowTblPropertiesSuite, ShowTablesSuite or ShowCreateTableSuite can easily miss it. loadTable is available in all v2 command suites, so could we split this per command? The SHOW CREATE TABLE part could then reuse getShowCreateDDL.

Split the coverage across DescribeTableSuite, ShowTblPropertiesSuite, ShowTablesSuite, and ShowCreateTableSuite. The SHOW CREATE TABLE test now uses getShowCreateDDL() and compares the full expected DDL.

nit: checkAnswer gives an exact comparison and a diff on failure. assert(properties.exists(...)) only reports "... was false", and the toMap + per-key asserts can't detect unexpected extra rows such as a leaked reserved key. For example:

checkAnswer(
  sql(s"DESCRIBE TABLE EXTENDED $tbl").where("col_name = 'Table Properties'"),
  Row("Table Properties", "[catalog-label=catalog-value,persisted=stored]", ""))
checkAnswer(
  sql(s"SHOW TBLPROPERTIES $tbl"),
  Seq(Row("catalog-label", "catalog-value"), Row("persisted", "stored")))

Replaced the hand-rolled checks with checkAnswer for the selected DESCRIBE rows and the full SHOW TBLPROPERTIES result, plus keyed-property checks. SHOW TABLE EXTENDED and SHOW CREATE TABLE now compare the complete expected output. The fixtures also include reserved keys and a collision with an existing property.

nit: these two members are inserted between version() and setVersion(), which splits the version-related members (version, setVersion, setVersionAndValidatedVersionFrom, ..., setValidatedVersion). AGENTS.md also asks us to follow the file's existing sectioning when adding members. Could we move them before version() (after updateColumns, following the columns/properties/displayProperties order in Table), or after setValidatedVersion?

Moved displayProperties() and setDisplayProperties() immediately after updateColumns(), before version(), so the version-related methods stay together.

nit: delegating to the interface default makes the intent clearer: behave like a regular connector when the display properties are unset.

Applied: the fixture now falls back to super.displayProperties(). With the additive contract, that default is an empty map.

Display-only keys share the key namespace that ALTER TABLE ... SET/UNSET TBLPROPERTIES manage, but those commands only change properties(). With the fixture in ShowTblPropertiesSuite (stored persisted=stored; display persisted=display-value and catalog-label=catalog-value):

• ALTER TABLE t UNSET TBLPROPERTIES ('persisted') removes the stored key, and then SHOW TBLPROPERTIES t ('persisted') returns display-value instead of "Table ... does not have property: persisted". getTableProperties still contains persisted, while SHOW CREATE TABLE no longer does.
• ALTER TABLE t UNSET TBLPROPERTIES ('catalog-label') succeeds, because V2 UnsetTableProperties only emits TableChange.removeProperty (a no-op for a missing key, per TableChange.java L63), but the key is still listed afterwards. No SQL can remove it, so a tool that syncs properties by diffing getTableProperties against a desired set never converges.
• SET TBLPROPERTIES ('catalog-label' = 'x') followed by UNSET brings catalog-value back.

Neither the Javadoc nor the tests cover this; ShowTblPropertiesSuite only exercises SET. Could the Table#displayProperties() Javadoc state that ALTER TABLE ... SET/UNSET TBLPROPERTIES only affect properties(), and that a display entry shows through once a colliding stored key is unset? An UNSET step in that test would pin it. Alternatively, rendering the display entries separately (the other option in #59036 (comment)) would avoid the shared namespace.

Documented that SET/UNSET only changes properties() and cannot remove catalog-controlled display entries. Extended ShowTblPropertiesSuite to check unsetting a colliding stored key, unsetting a display-only key, and SET followed by UNSET. It also checks that getTableProperties returns the display value after UNSET while the key is absent from getCreateTableString.

TableInfo is also the input of TableCatalog.createTable(Identifier, TableInfo), createTableLike and StagingTableCatalog.stage*, but this new field has no documented meaning on that path.

• Spark never sets it: CreateTableExec, ReplaceTableExec, WriteToDataSourceV2Exec (CTAS/RTAS), CreateTableLikeExec and the pipelines DatasetManager build TableInfo without it.
• The default TableCatalog.createTable(ident, tableInfo) (TableCatalog.java L359-362) and the StagingTableCatalog.stage* defaults flatten TableInfo to (columns, partitions, properties) and drop it. V2SessionCatalog and JDBCTableCatalog use that default, and DelegatingCatalogExtension doesn't override it, so it never reaches the delegate.
• The test catalogs in this PR persist it at create time (BasicInMemoryTableCatalog.createTable and InMemoryRowLevelOperationTableCatalog.createTable), and InMemoryRelationCatalog stores the whole TableInfo.

So a connector modeled on the test catalogs persists "display-only" entries at create time. Code that copies a metadata-only table with catB.createTable(ident, delegatingTable.getTableInfo()) freezes the source catalog's transient labels into catB on some catalogs and silently drops them on others. Could the Javadoc here and on withDisplayProperties say that Spark doesn't set it for create, replace, stage or createTableLike, and that catalogs may ignore it there?

Clarified both Javadocs: display properties describe metadata returned by a catalog, and Spark leaves them empty when calling createTable, createTableLike, stageCreate, stageReplace, or stageCreateOrReplace. Removed the create-time display-property setters from the two in-memory catalogs; the preservation test now sets the entries on the live table returned by createTable.

Apart from external, every reserved key in this display map is also stored on the table, so the test only checks which value wins. The table is created with COMMENT, LOCATION, USING _ and the default owner, so the display comment, location, provider and owner all collide with stored values. A display-only location, collation, table_type or is_managed_location is never exercised, which was the ask in #59036 (comment).

For example, suppose the reserved-row loop (DescribeTableExec L198-204, ShowTablesExtendedExec L93-99) were changed to read displayProperties ++ properties while Type stays on properties(). A table without a stored location would then show the display Location (or a Collation or Table_type row), but all the new tests would still pass because every table they use has a stored location. The col_name IN ('Type', 'Comment', 'Location', 'Provider', 'Owner', 'Table Properties') filter at L246 would also hide such a leaked row.

Could the display map be built from CatalogV2Util.TABLE_RESERVED_PROPERTIES, as CatalogV2UtilSuite does, with one table created without LOCATION, and could the filter cover all the reserved rows? The same 15-line fixture is repeated in ShowTablesSuite L77-91, so a shared helper next to loadTable in the v2 CommandSuiteBase would keep the suites in sync.

Added a shared fixture in CommandSuiteBase that supplies every key in TABLE_RESERVED_PROPERTIES. Both DESCRIBE and SHOW TABLE EXTENDED now test managed/external tables with and without a stored LOCATION. The DESCRIBE assertion includes all reserved rows, and SHOW TABLE EXTENDED checks the complete output.

The metadata-only path this enables (TableInfo.Builder.withDisplayProperties + DelegatingTable) is only covered by unit tests. CatalogSuite and CatalogV2UtilSuite call displayProperties() and tablePropertiesForDisplay directly, and every SQL-level test uses InMemoryBaseTable.setDisplayProperties. No test runs DESCRIBE TABLE EXTENDED, SHOW TBLPROPERTIES or SHOW TABLE EXTENDED against a catalog that returns a DelegatingTable.

That path is special-cased elsewhere: RelationResolution L464-468 treats DelegatingTable as an "interpret via v1" sentinel for reads, and V1Table.toCatalogTable(catalog, ident, DelegatingTable) reads only info.properties. If the metadata commands were ever routed the same way, display entries would disappear for metadata-only catalogs without any failing test. Could we add one end-to-end test? InMemoryRelationCatalog is already registered in v2 ShowTablesSuite, and a catalog that builds the TableInfo in loadTable, like TestingDataSourceTableCatalog in DataSourceV2MetadataTableSuite, would also work.

Added an end-to-end test in DataSourceV2MetadataTableSuite. Its catalog builds TableInfo with display properties in loadTable and returns a DelegatingTable. The test exercises DESCRIBE TABLE EXTENDED, SHOW TBLPROPERTIES, SHOW TABLE EXTENDED, and getTableProperties, and verifies that getCreateTableString excludes the display-only entry.

Display-only entries are a new input to three redacted outputs, but no test checks that they are redacted. Today DescribeTableExec L206, ShowTablePropertiesExec L35 and ShowTablesExtendedExec L102 redact the merged map, which is right. However, the new fixtures only use catalog-label, persisted and reserved keys, none of which matches spark.redaction.regex or spark.sql.redaction.options.regex. The existing redaction test (SHOW TBLPROPERTIES BASIC in ShowTblPropertiesSuiteBase) only covers a stored password property.

If a later change redacted properties() before merging, a connector's display entry such as password or jdbc_url would be printed in clear by DESCRIBE TABLE EXTENDED, SHOW TBLPROPERTIES, SHOW TABLE EXTENDED and getTableProperties, and no test would fail. Could this test add a display-only password entry and expect *********(redacted)?

Added a display-only password to the shared fixture and asserted *********(redacted) in DESCRIBE TABLE EXTENDED, SHOW TBLPROPERTIES (including single-key lookup), and SHOW TABLE EXTENDED. The catalog API test also verifies redaction in getTableProperties.

This holds for InMemoryTableCatalog, but the session-catalog test catalog still drops display state on ALTER TABLE. InMemoryTableSessionCatalog.alterTable (DataSourceV2DataFrameSessionCatalogSuite.scala L160-181) rebuilds the table as new InMemoryTable(table.name, schema, table.partitioning, properties) without copying the display properties. That catalog is how the tests model a session-catalog extension that returns V2 tables (DatasourceV2SQLBase registers it as spark_catalog), which is the case the PR description says DESCRIBE TABLE EXTENDED and SHOW TBLPROPERTIES support. There, after setDisplayProperties on the live table and ALTER TABLE t SET TBLPROPERTIES ('k' = 'v'), SHOW TBLPROPERTIES t no longer lists the display entry.

No current test hits this, and that rebuild already reset the version before this PR. But since #59036 (comment) says table reconstruction during ALTER TABLE preserves the entries, could it also call setDisplayProperties(table.displayProperties())?

Added setDisplayProperties(table.displayProperties()) when the session-catalog fixture reconstructs a table. A new regression test checks SHOW TBLPROPERTIES and DESCRIBE TABLE EXTENDED after SET, and that the display entry survives a subsequent UNSET.

The rename replaced the explanation of why the version must be copied with a one-line summary. The previous Scaladoc said that replacement tables start with a version counter of 0, and that without this call the counter resets and breaks the monotonic-version assumption that InMemoryTable.copy, validated-version propagation and the join-refresh tests in DSv2IncrementallyConstructedQueryTests rely on. That is still true (the version-aware equals/hashCode below uses it), and it isn't documented anywhere else in the code, so the next person who adds a catalog that rebuilds tables may skip this call. Also, 5 of the 11 callers are copy() snapshots rather than replacement tables. Could we keep the old paragraph and just add the display-only metadata to the first sentence?

Restored the paragraph explaining why the version must be copied, and changed the summary to cover version, validated version, and display-only metadata copied from another table.

nit: this copies the table state by hand instead of calling copyTableStateFrom. Now that the helper is the generic "copy table state" hook, the most common ALTER TABLE path (test_catalog, InMemoryTableCatalog, InMemoryCatalog) still keeps its own list: setVersion + setDisplayProperties, and validatedVersion only for AddConstraint. InMemoryRowLevelOperationTableCatalog.alterTable carries validatedVersion over through the helper instead. If a field is later added only to copyTableStateFrom, this path resets it, and the catalogs that wrap super.alterTable (NullColumnIdInMemoryTableCatalog, MixedColumnIdTableCatalog, TypeChangeResetsColIdTableCatalog, ...) copy from the already-reset table. Could this call newTable.copyTableStateFrom(table) and keep the AddConstraint loop, or at least carry a comment to keep the two in sync?

Changed this path to call copyTableStateFrom and kept the AddConstraint loop. The preservation test also checks version copying and that validatedVersion survives a property alteration.

nit: this Notes section comes before Parameters. The other Notes sections in this file (e.g. listViews, functionExists and listColumns) come after Returns and before Examples, which is also the numpydoc order. The rendered API docs reorder it, but help(spark.catalog.getTableProperties) and IDEs show the raw order. Could it move below Returns?

Moved Notes below Returns and before Examples.

nit: the suite's before block already registers testcat as the same InMemoryCatalog class for every test, and the other V2 tests in this suite use it. Could this test use testcat and drop the withSQLConf wrapper?

Switched the test to the existing testcat and removed the withSQLConf wrapper.

The new API has no null contract, and this merge passes null values through. TableInfo.Builder.withDisplayProperties copies the map with new HashMap<>(...), which keeps null values, and Utils.redact passes them through. Take a connector that returns a DelegatingTable whose display map has "last_refresh" -> null for a value it doesn't know yet:

• SHOW TBLPROPERTIES t, SHOW TBLPROPERTIES t ('last_refresh') and spark.catalog.getTableProperties fail, because ShowTableProperties declares key and value as non-nullable (v2Commands.scala L1583-1584) and toCatalystRow rejects the null.
• DESCRIBE TABLE EXTENDED and SHOW TABLE EXTENDED print last_refresh=null.

If displayProperties() itself returns null, asScala returns null and .toMap throws an NPE in all three commands. ShowTablesExtendedExec has no per-table error handling, so one such table fails SHOW TABLE EXTENDED IN cat.ns LIKE '*' for the whole namespace.

properties() has the same exposure, but the SQL path rejects null property values, while these entries are computed by the catalog and may be transient. Could the Table#displayProperties() Javadoc say that the map and its keys and values must not be null, as TableCatalog#tableStateOptionKeys() does with "a non-null set"? Alternatively, this helper could drop null entries.

Added an explicit non-null map/keys/values contract to Table.displayProperties() and the TableInfo builder parameter. This uses the documented-contract approach rather than silently dropping invalid entries.

These two sentences describe the catalog's behavior as Spark's. On this path Spark never reads the display entries: SetTableProperties and UnsetTableProperties only produce TableChange.setProperty and TableChange.removeProperty, and AlterTableExec.scala L41 passes them to TableCatalog.alterTable. Whether a display entry survives SET, or disappears on UNSET, is up to the catalog:

• InMemoryTableSessionCatalog.alterTable dropped the display state on every ALTER TABLE until R2-9 was fixed.
• A catalog that handles removeProperty("label") by deleting its label contradicts "cannot be removed with UNSET TBLPROPERTIES".

Also, the second half of R2-1, that a display value shows through once a colliding stored key is unset, is only in the PR description. Could this paragraph be phrased as guidance for implementors? For example:

<p>Spark passes {@code ALTER TABLE ... SET/UNSET TBLPROPERTIES} to
{@link TableCatalog#alterTable} as {@link TableChange#setProperty} and
{@link TableChange#removeProperty} without consulting this map. Implementations should apply
them to {@code properties()} only and keep display-only entries unchanged. Then
{@code UNSET TBLPROPERTIES} of a display-only key succeeds but the key is still listed, and
unsetting a stored key that collides with a display-only key exposes the display-only value.

Reworded this as guidance for catalog implementations: Spark forwards SET/UNSET to alterTable without consulting the display map. The precedence paragraph now also states that, after a stored property is removed, Spark displays the entry for that key if it remains in the display map.

Minor: R2-2 also asked to say that catalogs may ignore this field on the create path, and that half is missing here and in the setter (L96-99). The default TableCatalog.createTable(Identifier, TableInfo) and the StagingTableCatalog.stage* defaults drop it, but a catalog that stores the whole TableInfo, such as InMemoryRelationCatalog, persists whatever a non-Spark caller put there, e.g. catB.createTable(ident, delegatingTable.getTableInfo()). Without that sentence, implementors can't tell whether to ignore it or store it. Could we add something like "Catalogs may ignore them in these methods."? The setter could then just refer to {@link TableInfo#displayProperties()}, so the five-method list lives in one place.

Removed the duplicated creation-method list from the builder documentation; it now lives only on the getter. I kept the scope to the current Spark behavior: these are returned metadata, and Spark leaves them empty on creation/staging calls. Since TableInfo is internal for now, I would prefer not to add a contract for non-Spark callers supplying this field on those paths.

Minor, pre-existing: this still decides Type by containsKey(PROP_EXTERNAL) alone and ignores PROP_TABLE_TYPE, although withTableType is the only type setter on TableInfo.Builder. For a DelegatingTable built with .withTableType(TableSummary.EXTERNAL_TABLE_TYPE), like the existing test_json fixture in DataSourceV2MetadataTableSuite:

• DESCRIBE TABLE EXTENDED prints both Type | MANAGED and Table_type | EXTERNAL.
• SHOW TABLE EXTENDED prints Type: MANAGED (ShowTablesExtendedExec.scala L86).
• SHOW TABLE EXTENDED ... AS JSON (through listTableSummaries) and V1Table.toCatalogTable treat it as EXTERNAL.

This is the external=false case from R1-2 seen from another side. It isn't introduced by this PR, and fixing it changes pinned outputs, so could we file a follow-up JIRA to derive Type from table_type first and fall back to external?

Agreed this is pre-existing and should be fixed separately by honoring table_type before the external fallback. Leaving that behavior unchanged in this PR. I have prepared the follow-up JIRA draft, but have not filed it yet.

nit: L191 hoists table.properties(), but tablePropertiesForDisplay(table) reads table.properties() again, so this command still reads it twice per table, and so does ShowTablesExtendedExec.scala (L85 and L102). Could the helper take the map the caller already has, e.g. tablePropertiesForDisplay(tableProperties, table.displayProperties())? Then the Type and reserved rows also come from the same snapshot as the Table Properties row.

Changed the helper to accept the stored and display property maps. DESCRIBE TABLE EXTENDED and SHOW TABLE EXTENDED now pass the stored map already fetched for the reserved metadata rows, so each reads properties() only once.