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
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 |