Search Postgresql Archives

Re: Cascade view drop permission checks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Apr 6, 2022 at 6:48 AM Tom Lane <tgl@xxxxxxxxxxxxx> 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.


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux