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
