dropping the backing table drops the materialized view

Question

When dropping a backing table for a materialized view, is it normal for the materialized view to be also dropped? I understand that the materialized view is invalid without the presence of the backing table, but dropping the materialized view seems a bit unusual.

The materialized views is created as follows

create materialized view if not exists ea_master.geography_hierarchy
as
Select 
 parent.geography_id  as parent_geography_id
 ,child.geography_id  as child_geography_id
from ea_master.Geography parent
join ea_master.Polygon pParent on pParent.polygon_id = parent.polygon_id 
join ea_master.Polygon pChild on ST_Contains(pParent.geometry, pChild.geometry)
join ea_master.Geography child on child.polygon_id  = pChild.polygon_id 
with no data;

The query used to drop the backing table: DROP TABLE ea_master.geography CASCADE;

Please note at some point the materialized view is refreshed with data before issuing the command to drop the backing table.

Answer 1

Thanks to @Raptélan on postgres-slack channel, who pointed to me the documentation for delete table with cascade parameter. As per the docs, it is expected behavior from the docs excerpt:

DROP TABLE always removes any indexes, rules, triggers, and constraints that exist 
for the target table. However, to drop a table that is referenced by a view or a 
foreign-key constraint of another table, CASCADE must be specified. (CASCADE will 
remove a dependent view entirely, but in the foreign-key case it will only remove 
the foreign-key constraint, not the other table entirely.)

Unfortunately looks like the cascade parameter is required to remove the backing table to ensure view is removed along with it. I will just have to recreate the view every time the backing table is deleted with the cascade option.

Also, I was conflating this cascade parameter to the foreign keys with on delete cascade parameter.