Re: Cascade view drop permission checks

On Wed, Apr 6, 2022 at 6:48 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> (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.

David J.