On Wed, Apr 6, 2022 at 6:48 AM Tom Lane 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 t
"David G. Johnston" writes:
> On Tuesday, April 5, 2022, m7o...@gmail.com wrote:
>> It seems strange to me that somebody who is not a member of owner role can
>> drop an object bypassing permission checks.
>> Is this behaviour OK?
> The system dropped the now defunct view, not alice. Bob accept
On Wednesday, April 6, 2022, m7o...@gmail.com wrote:
> David, thank you for the clarification.
> Should we consider raising log level for cascade drops from NOTICE to
> WARNING? By now cascade drops appears in log files only when log level >=
> NOTICE.
>
> --- a/src/backend/catalog/dependency.c
>
David, thank you for the clarification.
Should we consider raising log level for cascade drops from NOTICE to
WARNING? By now cascade drops appears in log files only when log level >=
NOTICE.
--- a/src/backend/catalog/dependency.c
+++ b/src/backend/catalog/dependency.c
@@ -1105,7 +1105,7 @@ report
On Tuesday, April 5, 2022, m7o...@gmail.com wrote:
>
> -- alice
> create or replace view sandbox_a.alice_view as
> select category, name, setting
> from pg_catalog.pg_settings;
>
> grant select on sandbox_a.alice_view to bob;
>
> -- bob
> create or replace view sandbox_b.bob_view as
> select di
Hello guys!
I've faced an interesting case with cascade drops. If we drop some view
that is dependency for another view then drop cascade will not check
permissions for cascade-droppping views.
Short example is:
create user alice with password 'apassword';
create user bob with password 'bpassword'
