cloud-fan commented on issue #25747: [SPARK-29039][SQL] centralize the catalog and table lookup logic URL: https://github.com/apache/spark/pull/25747#issuecomment-531630599 Hi @rdblue , thanks for taking a look! What I want to get consensus on is the categories of v1/v2 table resolution I mentioned in the PR description: 1. `StatementRequiringCatalog`. It carries an n-part name and needs to look up the catalog to resolve itself. If the returned catalog is v2 session catalog, leave the plan unchanged and wait for other rules to resolve it (e.g. convert it to v1 command) 2. `StatementRequiringCatalogAndTable`. It carries an n-part name and needs to look up the catalog and table to resolve itself. If the returned table is `V1Table`, leave the plan unchanged and wait for other rules to resolve it (e.g. convert it to v1 command) 3. general `ParsedStatement`. It carries `UnresolvedRelation` which will be resolved to temp view, view or tables. If we agree with this, I don't mind to use different extractors to implement this. I'll update this PR to use extractors.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services --------------------------------------------------------------------- To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org For additional commands, e-mail: reviews-h...@spark.apache.org
