Re: DROP OWNED BY fails to clean out pg_init_privs grants

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Hannu Krosing <hannuk(at)google(dot)com>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net>, Andres Freund <andres(at)anarazel(dot)de>, Noah Misch <nmisch(at)google(dot)com>
Subject: Re: DROP OWNED BY fails to clean out pg_init_privs grants
Date: 2024-06-04 13:30:19
Message-ID: CA+TgmoY0N9F9qLcL06dwzyeJbW=+K6iNo5P-TBi5Jr6s=a81FA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 28, 2024 at 9:06 PM Hannu Krosing <hannuk(at)google(dot)com> wrote:
> We should definitely also fix pg_dump, likely just checking that the
> role exists when generating REVOKE commands (may be a good practice
> for other cases too so instead of casting to ::regrole do the actual
> join)
>
> ## here is the fix for pg_dump
>
> While flying to Vancouver I looked around in pg_dump code, and it
> looks like the easiest way to mitigate the dangling pg_init_priv
> entries is to replace the query in pg_dump with one that filters out
> invalid entries

+1 for this approach. I agree with Tom that fixing this in REVOKE is a
bad plan; REVOKE is used by way too many things other than pg_dump,
and the behavior change is not in general desirable.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2024-06-04 14:09:46 Re: Logical Replication of sequences
Previous Message Robert Haas 2024-06-04 13:26:27 Re: relfilenode statistics