| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Signed-off-by: wucm667 <stevenwucongmin@gmail.com>
|
Would love for this to be considered - I believe it fixes my exact issue, so thank you @wucm667 |
Sorry, something went wrong.
|
I just closed #4456 in favor of this — I worked the same fix independently before finding yours. Same approach lands at the same place, so this is the one to merge. One thing I tried that's worth a quick consider: In internal/sql/ast, the pg_query DropBehavior enum (UNDEFINED=0, RESTRICT=1, CASCADE=2) is checked as Behavior == 2 in dropTable(). Adding named constants in drop_behavior.go: const (
DropBehaviorUndefined DropBehavior = 0
DropBehaviorRestrict DropBehavior = 1
DropBehaviorCascade DropBehavior = 2
)and using stmt.Behavior == ast.DropBehaviorCascade reads more intent-fully and would survive a future pg_query enum reshuffle. Tiny patch, no behavior change. Happy to PR it as a follow-up if you and the maintainers like it. Otherwise this looks solid — the RangeVar walk for view DependsOn is the natural place to capture deps, and the transitive eviction handles the views-on-views case I was worried about. |
Sorry, something went wrong.
|
@luongs3 Thanks for the kind words and for the suggestion! I agree the named constants @kyleconroy @jzelinskie Would love a review when you have a moment 🙂 |
Sorry, something went wrong.
|
Follow-up draft up at #4461 — just the named DropBehavior constants, no use-site changes. Tagging here so it's discoverable from this thread. Happy for it to land independently before this PR, or for the rename to be folded into this PR (or a sweep PR after this merges) — whichever the maintainers prefer. Will keep #4461 in draft until there's a signal either way. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Problem
When sqlc generate replays a PostgreSQL schema containing DROP TABLE ... CASCADE, dependent views remain in the internal catalog. This causes subsequent CREATE VIEW statements with the same name to fail with relation "vw_reference_rates" already exists.
Minimal repro (Playground):
In real Postgres, DROP TABLE ... CASCADE drops both the table and dependent views. In sqlc's replay, the view persists.
Root Cause
Fix
1. Capture CASCADE/RESTRICT in the AST (internal/sql/ast/drop_table_stmt.go)
Added Behavior DropBehavior field.
2. Parser extracts Behavior (internal/engine/postgresql/parse.go)
When converting DropStmt for OBJECT_TABLE, OBJECT_VIEW, or OBJECT_MATVIEW, pass through n.Behavior.
3. Track view dependencies (internal/sql/catalog/view.go)
Added DependsOnTables []*ast.TableName to Table struct. The createView function now walks the SELECT query AST to extract all RangeVar (table reference) nodes, populating dependencies at view creation time.
4. CASCADE drops dependent views (internal/sql/catalog/table.go)
When Behavior == 2 (DROP_CASCADE in pg_query_go protobuf), dropTable scans all tables/views in the schema and removes any that depend on the dropped table.
5. Tests (internal/engine/postgresql/catalog_test.go)
Testing
All existing TestUpdateErrors cases pass; new CASCADE tests pass.
Fixes #4416