Is your feature request related to a problem or challenge? Please describe what you are trying to do.
Currently SqlToRel takes a ContextProvider on which it calls ContextProvider::get_table_provider whilst it traverses the SQL AST. If a table appears multiple times in the same query, it will call ContextProvider::get_table_provider multiple times, and obtain potentially different Arc<dyn TableSource> for the same table.
This is perfectly fine, provided TableSource are not interior mutable, that is their contents can't change. However, in a system supporting mutation, it is unclear how to provide a consistent snapshot of that data to the query.
The obvious place to obtain this snapshot would be when constructing the TableSource / TableProvider in SchemaProvider, however, as this method gets called multiple times this would potentially result in multiple snapshots for the same query.
Describe the solution you'd like
Some component, likely SessionContext, should first identify all the relations that appear in the query and obtain a snapshot of each unique TableSource by calling SchemaProvider::table. This immutable state can then be handed off to SqlToRel to produce the LogicalPlan.
Describe alternatives you've considered
TableProvider could potentially infer some notion of session state based on the session_id, but it is unclear how this would work with multiple concurrent queries on the same SessionContext.
Additional context
#4617 tracks the general issue of mutation isolation
#4607 implements a form of this as part of supporting async catalogs
Is your feature request related to a problem or challenge? Please describe what you are trying to do.
Currently
SqlToReltakes aContextProvideron which it callsContextProvider::get_table_providerwhilst it traverses the SQL AST. If a table appears multiple times in the same query, it will callContextProvider::get_table_providermultiple times, and obtain potentially differentArc<dyn TableSource>for the same table.This is perfectly fine, provided
TableSourceare not interior mutable, that is their contents can't change. However, in a system supporting mutation, it is unclear how to provide a consistent snapshot of that data to the query.The obvious place to obtain this snapshot would be when constructing the
TableSource/TableProviderinSchemaProvider, however, as this method gets called multiple times this would potentially result in multiple snapshots for the same query.Describe the solution you'd like
Some component, likely
SessionContext, should first identify all the relations that appear in the query and obtain a snapshot of each uniqueTableSourceby callingSchemaProvider::table. This immutable state can then be handed off toSqlToRelto produce theLogicalPlan.Describe alternatives you've considered
TableProvidercould potentially infer some notion of session state based on thesession_id, but it is unclear how this would work with multiple concurrent queries on the sameSessionContext.Additional context
#4617 tracks the general issue of mutation isolation
#4607 implements a form of this as part of supporting async catalogs