Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES
Nathan Bossart <bossartn@amazon.com>
From: "Bossart, Nathan" <bossartn@amazon.com>
To: Tom Lane <tgl@sss.pgh.pa.us>, Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Neil Chen <carpenter.nail.cz@gmail.com>, "Boris P. Korzun" <drtr0jan@yandex.ru>, "pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>
Date: 2021-10-19T21:01:13Z
Lists: pgsql-bugs, pgsql-hackers
On 10/19/21, 12:54 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
> I kind of wonder now whether the existing behavior is correct for either
> case. Why aren't we simply regurgitating the pg_default_acl entries
> verbatim? That is, I think maybe we don't need the acldefault call at
> all; we should just use null/empty as the starting ACL in all cases
> when printing pg_default_acl entries. Like this:
Hm. If we do this, then this command:
ALTER DEFAULT PRIVILEGES FOR ROLE myrole REVOKE ALL ON FUNCTIONS FROM PUBLIC;
is dumped as:
ALTER DEFAULT PRIVILEGES FOR ROLE myrole GRANT ALL ON FUNCTIONS TO myrole;
This command is effectively ignored when you apply it, as no entry is
added to pg_default_acl. I haven't looked too closely into what's
happening yet, but it does look like there is more to the story.
Nathan
Commits
-
pg_dump: fix mis-dumping of non-global default privileges.
- b1df061f704b 9.6.24 landed
- 871dfe4b7270 11.14 landed
- 52b927a731e5 12.9 landed
- 476006023538 13.5 landed
- 10f9faf6d873 10.19 landed
- 3ad2c2455be0 14.1 landed
- 2acc84c6fd29 15.0 landed