Re: Cascade view drop permission checks

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: "m7onov(at)gmail(dot)com" <m7onov(at)gmail(dot)com>
Cc: "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Cascade view drop permission checks
Date: 2022-04-06 12:16:01
Message-ID: CAKFQuwaykqdGWSQ+BSWjgr=dngYY5m5=mV+mbwwb5T3sjtfmvw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wednesday, April 6, 2022, m7onov(at)gmail(dot)com <m7onov(at)gmail(dot)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
> +++ b/src/backend/catalog/dependency.c
> @@ -1105,7 +1105,7 @@ reportDependentObjects(const ObjectAddresses
> *targetObjects,
> int flags,
> const ObjectAddress *origObject)
> {
> - int msglevel = (flags & PERFORM_DELETION_QUIETLY) ? DEBUG2 : NOTICE;
> + int msglevel = (flags & PERFORM_DELETION_QUIETLY) ? DEBUG2 : WARNING;
> bool ok = true;
> StringInfoData clientdetail;
> StringInfoData logdetail;
>

Please don’t top-post.

There is no point that I can see unless you also argue to warn/log about
every dropped object. Which can be done by the dba using event triggers if
they really want to.

They said cascade and got cascade. And can in-client set to notice and use
a transaction.

David J.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2022-04-06 13:48:41 Re: Cascade view drop permission checks
Previous Message Ajin Cherian 2022-04-06 11:37:06 Re: Support logical replication of DDLs