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

  1. pg_dump: fix mis-dumping of non-global default privileges.