(b) what other behavior would be better? Dropping the table and leaving a broken view behind isn't good. Neither is refusing to let the owner drop her object.
CREATE OR REPLACE VIEW name
SELECT null::type, null::type, null::type;
Where the column count and types allow the "OR REPLACE" behavior to work.
Now the owner of the view can put an alternate implementation in place, and the lack of a delete on the view prevents further cascading.
It has its flaws and benefits, but so does having objects drop. I suppose if we did have this kind of behavior we'd probably also have a way to inform the system that, basically, there are no select privileges (or some other spelling of "invalid") on the view, so any attempt to query the view would fail even while the view still exists.
