So what happens here (on both Postgres and Redshift) is that views are “bound” to the objects they depend on. Let’s say you have a view,
my_view, that selects from
my_incremental_model. If you try to run:
drop table my_incremental_model
postgres is going to be unhappy with you, saying something like:
ERROR: table my_incremental_model cannot be dropped because some objects depend on it
As a result, dbt is forced to use the
cascade qualifier, which drops the table, and all objects that depend on it.
drop table my_incremental_model cascade
This has the result of dropping
my_view as well!
On Redshift, you can get around this by using late binding views, hence the snippet of code I was suggesting. But on Postgres, there’s no equivalent feature.
Instead, I recommend ensuring that all models that are referenced in your BI tool are materialized as tables – even though tables select from other models, they don’t have the same binding behavior, so won’t get dropped by the