Refactor(optimizer): improve handling of DDL optimization #1972
Conversation
| @@ -990,7 +990,7 @@ class Uncache(Expression): | |||
| arg_types = {"this": True, "exists": False} | |||
|
|
|||
|
|
|||
| class TableChange(Expression): | |||
| class DDL(Expression): | |||
There was a problem hiding this comment.
I didn't have UPDATE inherit from this on purpose because it doesn't have a Subqueryable expression like CREATE and INSERT, so it'd need more effort to qualify / optimize its SET .. FROM .. syntax. Perhaps we could tackle this in a future PR.
| with_ = scope.expression.args.get("with") | ||
| if with_ and with_.recursive: |
There was a problem hiding this comment.
In WITH ... CREATE ... AS SELECT ... the CTEs are not attached to the SELECT, so args["with"] would raise a KeyError here.
| query_scope = scope.branch( | ||
| scope.expression.expression, scope_type=ScopeType.DERIVED_TABLE, chain_sources=scope.sources | ||
| ) |
There was a problem hiding this comment.
Picked DERIVED_TABLE here because ROOT is already taken for the DDL statement itself. Might not be the cleanest approach but I think it's fine for now?
|
Regarding the comment I left here #1949 (comment), it seems like this is a known "issue" based on: sqlglot/tests/fixtures/optimizer/qualify_tables.sql Lines 17 to 20 in 9d67283 I assume this is because when we do |
georgesittas
force-pushed
the
jo/optimize_ddls
branch
from
fe30934 to
719bea2
Compare
cc @gtoonstra
Maybe the name
DDLisn't the best for this, given thatINSERTis actually in the DML category..