Skip to content

feat: add SchemaProvider::table_type(table_name: &str) #16401

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

epgif
Copy link

@epgif epgif commented Jun 13, 2025

InformationSchemaConfig::make_tables only needs the TableType not the whole TableProvider, and the former may require an expensive catalog operation to construct and the latter may not.

This allows avoiding SELECT * FROM information_schema.tables having to make 1 of those potentially expensive operations per table.

InformationSchemaConfig::make_tables only needs the TableType not the
whole TableProvider, and the former may require an expensive catalog
operation to construct and the latter may not.

This allows avoiding `SELECT * FROM information_schema.tables` having to
make 1 of those potentially expensive operations per table.
@github-actions github-actions bot added the catalog Related to the catalog crate label Jun 13, 2025
Copy link
Contributor

@alamb alamb left a comment

Choose a reason for hiding this comment

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

This feature makes sense to me -- thank you @epgif

I wonder if there is some way we can write a test for it (mostly to prevent it from being accidentally broken/changed in the future)

Maybe an example or something 🤔

@epgif
Copy link
Author

epgif commented Jun 13, 2025

@alamb

I wonder if there is some way we can write a test for it (mostly to prevent it from being accidentally broken/changed in the future)

I looked around for some tests implementing this interface that I could extend, but didn't find any. I meant to ask earlier but forgot: is there anything like that? It would be a big help if I had some previous tests to take inspiration from.

Failing that, I'll take a stab at it anyway :)

Thanks!

/// returns `None`. Implementations for which this operation is cheap but [Self::table] is
/// expensive can override this to improve operations that only need the type, e.g.
/// `SELECT * FROM information_schema.tables`.
async fn table_type(&self, name: &str) -> Result<Option<TableType>, DataFusionError> {
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
async fn table_type(&self, name: &str) -> Result<Option<TableType>, DataFusionError> {
async fn table_type(&self, name: &str) -> DataFusionResult<Option<TableType>> {

/// expensive can override this to improve operations that only need the type, e.g.
/// `SELECT * FROM information_schema.tables`.
async fn table_type(&self, name: &str) -> Result<Option<TableType>, DataFusionError> {
self.table(name).await.map(|o| o.map(|t| t.table_type()))
Copy link
Contributor

Choose a reason for hiding this comment

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

is there any way to avoid nested map? perhaps flat_map or and_then ? would me more readable IMHO

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
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants