fix(truncate): include materialized views in TRUNCATE#1751
Merged
Conversation
When MATERIALIZE VIEWS ... AS $$ ... $$ is used with WITH truncate, the materialized views are stored in schema-view-list (because fetch-columns is called with :table-type :view) rather than schema-table-list. truncate-tables only iterated over table-list, so the TRUNCATE statement was never generated for any matview — the summary showed 'Truncate: 0' even when truncate was requested. The COPY phase already does the right thing: optimize-table-copy-ordering uses (nconc table-list view-list). Align truncate-tables to match. Closes #1591.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When using
MATERIALIZE VIEWS view_name AS $$ SELECT ... $$together withWITH truncate, the pre-COPY TRUNCATE step silently skips every materialized view.The root cause:
fetch-metadatacallsfetch-columnswith:table-type :viewfor materialized views, so they land inschema-view-listrather thanschema-table-list.truncate-tablesbuilt its target list exclusively from(table-list catalog), which only returnsschema-table-listentries. The TRUNCATE SQL was therefore never generated for any matview regardless of any subsequentALTER TABLE NAMES MATCHING ... RENAME TO.The COPY phase already did the right thing —
optimize-table-copy-orderinguses(nconc table-list view-list)— but the TRUNCATE step had not been updated to match.Fix
Include
(view-list catalog-or-table)alongside(table-list catalog-or-table)in thecatalogandschemabranches oftruncate-tables. Thetablebranch is unchanged (a single table object is always concrete).v4 status
Not affected. Matviews with an explicit SQL definition are handled by
materialize-views!which always runsDROP TABLE IF EXISTS+CREATE TABLEbefore COPY. Matviews without an explicit SQL definition are merged intocatand go through the regular per-entry TRUNCATE loop. Neither path has this miss.Closes #1591.