-
Notifications
You must be signed in to change notification settings - Fork 39
Description
There's multiple reasons why do we in serenedb think it will be helpful.
In general I think dependency order like this
- common
- connector
- logical_plan
4.1. runner
4.2. optimizer
Why is it helpful?
In serenedb our pipeline like this:
- parse query text
- collect everything (in hashmap like struct) that looks like catalog reference from pg parser ast
- resolve (single time one for all => DDL snapshot) collected catalog objects via catalog
- use resolved objects in our PlanBuilder-like class to build logical_plan from pg parser ast
Right now we pass inside Axiom logical plan fake names that will be resolved with our own SchemaResolver that is knows that this is fake.
It's not convenient, neither effective.
It will be really convenient to create logical plan objects with already known table ptr/etc.
Btw in such case we can remove std::enable_shared_from from axiom::connector::Table maybe something else
For an example common Session will be unnecessary abstraction in such case.
How this would look for Axiom tests/Hive connector/etc?
I will add/move resolve + resolve cache in logical_plan PlanBuilder.
CC: @mbasmanova WDYT?