Skip to content

feat: show extension type names in DESCRIBE and information_schema.columns - #26893

Merged
alamb merged 6 commits into
apache:mainfrom
cblp:extension-type-names-in-describe
Nov 3, 2026
Merged

alamb merged 6 commits into
apache:mainfrom
cblp:extension-type-names-in-describe

Conversation

@cblp

@cblp cblp commented Oct 29, 2026 •

Copy link
Copy Markdown
Contributor

Which issue does this PR close?

Rationale for this change

DESCRIBE, SHOW COLUMNS and information_schema.columns show the storage type of a column, even if the column has a registered extension type. For example, a UUID column is shown as FixedSizeBinary(16). Extension types can already customize how their values are formatted, but not how their type is named.

With the canonical extension types registered, DESCRIBE of a table with a UUID column u and a plain column i now shows:

u UUID  YES
i Int32 NO

Before, the first row was u FixedSizeBinary(16) YES.

What changes are included in this PR?

  • New method DFExtensionType::display_name(&self) -> Option<Cow<'_, str>>. The default returns None, which means that the storage type is shown, as before. A name can be static, borrowed from the type or computed from its metadata, so parameterized names are possible.
  • New function datafusion_expr::extension_types::append_field_type_display_name(registry, field, builder). It appends the display name of the registered extension type of the field to a StringBuilder, or else the storage type. It also appends the storage type if the extension type is not registered or cannot be created from the field metadata, so that DESCRIBE does not fail on such a column.
  • InformationSchemaColumnsBuilder, which DESCRIBE, SHOW COLUMNS and information_schema.columns share, uses this function with the registry from with_extension_type_registry.
  • InformationSchemaProvider::with_extension_type_registry passes the session registry to that builder. The physical planner and SessionState set it where they create the provider.
  • DFUuid returns UUID and DFJson returns JSON. The other canonical extension types keep showing their storage type. I was not sure which names to use for them (for example for tensors, whose names would depend on the metadata) and am happy to add them here or in a follow-up.

The canonical extension types are not registered in a default session, so the default output does not change.

What is the testing strategy for this PR?

  • extension_type_names.slt registers the canonical extension types and a table with columns of registered types with and without a display name, of an unregistered extension type and of a plain type. It checks DESCRIBE, information_schema.columns, SHOW COLUMNS and a view.
  • A unit test for append_field_type_display_name, including the fallbacks.

Are there any user-facing changes?

Yes, sessions that register extension types with a display name, such as the canonical arrow.uuid and arrow.json, show that name in DESCRIBE, SHOW COLUMNS and information_schema.columns.

There are no breaking API changes: the new trait method has a default implementation.

…lumns

Add `DFExtensionType::display_name`, which returns the name of the type
shown by schema introspection. The default returns `None`, which keeps
showing the storage type. `DFUuid` returns `UUID` and `DFJson` returns
`JSON`.

`field_type_display_name` resolves the name of a field type with the
session's extension type registry. It falls back to the storage type if
the extension type is not registered or cannot be created from the field
metadata. `DESCRIBE` and `information_schema.columns`, and so
`SHOW COLUMNS`, use it.
@github-actions github-actions Bot added logical-expr Logical plan and expressions core Core DataFusion crate sqllogictest SQL Logic Tests (.slt) catalog Related to the catalog crate common Related to common crate labels Oct 29, 2026
sdf-jkl
sdf-jkl previously requested changes Nov 2, 2026

@sdf-jkl sdf-jkl left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @cblp! Some simplifications we could do

cblp added 2 commits November 3, 2026 16:09
…in-describe

`DESCRIBE`, `SHOW COLUMNS` and `information_schema.columns` now share
`InformationSchemaColumnsBuilder`, so the builder resolves the display
name of extension types with the registry that `InformationSchemaProvider`
passes to it.
Address review feedback:
- `DFExtensionType::display_name` returns `Option<Cow<'_, str>>`, so
  fixed names such as `UUID` and `JSON` need no allocation.
- `append_field_type_display_name` replaces `field_type_display_name`
  and appends the name to a `StringBuilder`, writing the storage type
  into it without an intermediate `String`.
@cblp

cblp commented Nov 3, 2026 •

Copy link
Copy Markdown
Contributor Author

@sdf-jkl applied all, thanks

@alamb
alamb requested a review from sdf-jkl November 3, 2026 20:39
alamb and others added 3 commits November 3, 2026 15:43
Register the canonical extension types for `sql_extension_types.slt`
instead of adding a new slt file. That file already creates UUID and JSON
columns with SQL, so the custom `ext` table is not needed. The fallback
cases are covered by the unit test of `append_field_type_display_name`.

Also cover `DESCRIBE <query>`, and restore the doc comment of
`register_metadata_tables`.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

@alamb alamb left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you @cblp and @sdf-jkl -- this looks great to me.

I took the liberty of adding a few more tests, and consolidating into an existing .slt file.

I also moved append_field_type_display_name into the information schema builder module as it seems like it is a internal helper function and is unlikely to be needed outside (it takes a StringBuider, for example)

@alamb
alamb dismissed sdf-jkl’s stale review November 3, 2026 20:59

Changes addressed

@alamb

alamb commented Nov 3, 2026

Copy link
Copy Markdown
Contributor

Merging this in so I can propose adding it to DataFusion 56

@alamb
alamb added this pull request to the merge queue Nov 3, 2026
@alamb alamb mentioned this pull request Nov 3, 2026
19 of 42 tasks
Merged via the queue into apache:main with commit 608ac9c Nov 3, 2026
43 of 44 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

catalog Related to the catalog crate common Related to common crate core Core DataFusion crate logical-expr Logical plan and expressions sqllogictest SQL Logic Tests (.slt) v57.0.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Support extension type names in schema introspection

3 participants