dropping the backing table drops the materialized view - postgresql

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.