updated limitations

dbt-labs · Jul 19, 2023 · 586edd3 · 586edd3
1 parent fe667ba
commit 586edd3
Show file tree

Hide file tree

Showing 2 changed files with 28 additions and 15 deletions.
diff --git a/website/docs/reference/resource-configs/postgres-configs.md b/website/docs/reference/resource-configs/postgres-configs.md
@@ -152,22 +152,10 @@ models:
 
 ### Limitations
 
-#### Changing materialization to and from "materialized_view"
+#### Changing materialization from "materialized_view" to table or view
 
-Swapping an already materialized model to be a materialized view and vise versa. The workaround is the manually drop the existing materialization in the data warehouse before calling `dbt run` again.
+Swapping a materialized view to be a table or view is not supported. The workaround is the manually drop the existing materialized view in the data warehouse before calling `dbt run` again.
 
-To illustrate, assume for the example model below, `my_model`, that it has already been materialized to the underlying data platform via `dbt run`. If a user then changes the model's config to be `materialized="materialized_view"`, they will get an error. The workaround is to execute `DROP TABLE my_model` on the data warehouse before trying the model again.
-
-<File name='my_model.sql'>
-
-```yaml
-
-{{ config(
-    materialized="table" # or any model type eg view, incremental
-) }}
-
-```
-
-</File>
+To illustrate, assume for a materialized view, `my_mv.sql`, has already been materialized to the underlying data platform via `dbt run`. If a user then changes the model's config to be `materialized="view"`, they will get an error. The workaround is to execute `DROP MATERIALIZE VIEW my_mv CASCASE` on the data warehouse before trying the model again.
 
 </VersionBlock>
diff --git a/website/docs/reference/resource-configs/redshift-configs.md b/website/docs/reference/resource-configs/redshift-configs.md
@@ -138,4 +138,29 @@ models:
 
 </File>
 
+### Limitations
+
+#### Changing materialization to and from "materialized_view"
+
+Swapping an already materialized model to be a materialized view and vise versa.
+
+This works with 
+
+ The workaround is the manually drop the existing materialization in the data warehouse before calling `dbt run` again.
+
+To illustrate, assume for the example model below, `my_model`, that it has already been materialized to the underlying data platform via `dbt run`. If a user then changes the model's config to be `materialized="materialized_view"`, they will get an error. The workaround is to execute `DROP TABLE my_model` on the data warehouse before trying the model again.
+
+<File name='my_model.sql'>
+
+```yaml
+
+{{ config(
+    materialized="table" # or any model type eg view, incremental
+) }}
+
+```
+
+</File>
+
+
 </VersionBlock>