Repository navigation
Conversation
3ec152b to
71f0578
Compare
sql module
71f0578 to
2449656
Compare
|
Thank you for opening this pull request! Reviewer note: cargo-semver-checks reported the current version number is not SemVer-compatible with the changes in this pull request (compared against the base branch). Details |
99ef998 to
21dafce
Compare
…e#25887) ## Which issue does this PR close? - Closes apache#15960. - Supersedes / closes apache#24200. - Prerequisite for PR apache#26057. ## Rationale for this change Catalog-qualified information schema queries currently return metadata for object from every registered catalog. If we follow the letter of the SQL specification, `my_catalog.information_schema.tables` should describe only `my_catalog`. This is consistent with PostgreSQL's information schema representing the current database. When working with multiple catalogs, for instance multiple Iceberg REST catalogs, it is more practical to be able to query just the objects defined in one specific catalog without further filtering. A special 'system' catalog is optionally provided to be able to query across catalogs. This can be seen as an approximation of SQL's definition schema. ## What changes are included in this PR? - The catalog list provided to `InformationSchemaProvider` is now constructed dynamically based on the catalog being queried. An optional 'system' catalog provides the existing global catalog behaviour. All other catalogs are restricted to just their own content. - Unqualified information_schema queries now use the configured default catalog instead of returning metadata from all catalogs. ## What is the testing strategy for this PR? Added multi-catalog SQL logic coverage for qualified and unqualified information schema queries. ## Are there any user-facing changes? Yes. Information schema results are now scoped to the resolved catalog. --------- Co-authored-by: Vaibhave Sekar <vsekar@microsoft.com> Co-authored-by: Andrew Lamb <andrew@nerdnetworks.org>
21dafce to
bc723c5
Compare
sql moduleshow statement implementation out of sql module
show statement implementation out of sql moduleshow statement implementations out of sql module
show statement implementations out of sql moduleLogicalPlan::DescribeTable to LogicalPlan::Show move statement implementations out of sql module
The test still used SessionConfig::with_system_catalog, which this branch replaced with with_partition_information_schema. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
alamb
left a comment
There was a problem hiding this comment.
Thank you @pepijnve
I really like this PR and I think it moves the code into a better shape (and it has restored my enjoyment of reviewing PRs for today)
Also, thank you for the very nice explanation / description on this PR. It has been a while since I read a description of that length that wasn't AI vomit and was a pleasure to read rather than making my brain hurt.
I also removed some redundant rust tests to slim down the size of the PR
While reviewing this PR one thing I was wondering is why we need to special case the InformationTable views.
I wonder what you think about following the DynamicFileCatalog approach and adding InformationSchema support as a wrapper.
So basically it would be automatically added to any catalog registered, like here
datafusion/datafusion/core/src/execution/context/mod.rs
Lines 415 to 432 in 02b7149
SHOW TABLES would still have to remain a rewrite into
SELECT * FROM information_schema.tables
But after that it would be planned like any other table
And then we could just remove LogicalPlan::DescribeTables (rather than renaming it)
| use std::fmt::Debug; | ||
| use std::sync::Arc; | ||
|
|
||
| /// Name of the `information_schema` schema |
There was a problem hiding this comment.
I like how much simpler this code is
|
|
||
| /// Builds `information_schema.views` rows. | ||
| #[derive(Debug)] | ||
| pub struct InformationSchemaViewBuilder { |
There was a problem hiding this comment.
it took me a while to understand why this stuff was moved to common, and then I realized it is because the LogicalPlan now depends on the information schema to report its schema 🤔
There was a problem hiding this comment.
Indeed. I wanted to avoid duplicating the schema in multiple places. By keeping the schema itself and builders for the arrays together it's easier to modify these going forward.
Looking at this again, I think we could move it from common to expr. Everything else that needs this is dependent on that crate already as well.
There was a problem hiding this comment.
Thanks for challenging the common location. I've done the move to expr; that makes more sense. A similar pattern could be applied for explain as well.
I'll need to give that some thought. In this PR I was just continuing on what was already there and didn't consider this alternative.
I think that would reintroduce the need for the global information schema and move the translation back into By implementing the |
3be8830 to
570be77
Compare
Which issue does this PR close?
This PR builds on #25887 so that should be merged first.
Rationale for this change
LogicalPlanhas a representation for theDESCRIBE TABLEstatement, but not for the variousSHOW ...statements. This makes it necessary to lowerSHOWstatements to equivalentSELECTstatements against theinformation_schematables during SQL statement to logical plan conversion. The code in question is located in thesqlmodule'sSqlToRel::sql_statement_to_planfunction.As an example,
show_tables_to_planis implemented asThe implementation is simple enough, but has the downside that it hardcodes references to tables and their columns using magic strings in a module that should be independent of specific schemas, tables, and views. The exact set of columns (and hence the output format) of the
showstatements is being determined in thesqlmodule which doesn't seem to be where it belongs. This is a logical-to-physical translation aspect, not a sql-to-logical one.To move the translation to a more appropriate location, this MR extends the logical plan data model to support
showstatements as well. Rather than introducing a new plan type, the existingdescribe tableplan type is extended to support all statements belonging to the family of introspection statements.The logical-to-physical translation of show statements is move over to the
physical_plannermodule next to the existing implementation fordescribe table.What changes are included in this PR?
LogicalPlan::DescribeTablehas been made been renamed toLogicalPlan::Showand extended to support all show statements.Handling of
showstatements has been moved fromsql::statementtocore::physical_planner.The implementations themselves have been decoupled from the
information_schematables. This allowsSHOWstatements to work even if the information schema provider is not enabled.A new
common::information_schemamodule has been added to avoid string based duplication of the information_schema schema. In other words, duplicate magic strings have been removed.Are these changes tested?
Covered by SLTs
Are there any user-facing changes?
Yes
LogicalPlan::DescribeTablehas been replaced withLogicalPlan::ShowSHOWstatements is no longer tied to theinformation_schemaschema being accessible in the cataloginformation_schema.viewsno longer contains base tables