Re: pg_dump dump catalog ACLs

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Jose Luis Tallon <jltallon(at)adv-solutions(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_dump dump catalog ACLs
Date: 2016-04-05 21:50:18
Message-ID: 20160405215018.GY10850@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jose, all,

While reviewing and considering this patch further, I realized that
a pg_upgrade correctly restored the privileges of extension objects, but
it didn't copy through the pg_init_privs catalog entries for those
extension objects, meaning that a further pg_dump wouldn't realize that
the extension objects had any initial privileges.

After looking at a few options, I settled on taking an approach similar
to how extension dependencies are handled and created a backend function
to help out with that issue. The backend function, only callable during
binary upgrade, sets a flag to let the system know that the GRANTs and
REVOKEs about to be executed need to be recorded into pg_init_privs,
just like they are done during a CREATE EXTENSION script. pg_dump now
pulls out, during a binary upgrade for extension objects, what the delta
is between the object's default privileges and what is recorded in
pg_init_privs and issues the necessary GRANT and REVOKE statements in a
block surrounded by setting/unsetting of the flag.

That turned out to simplify the regular pg_dump extraction process for
ACLs as that part could then simply always assume that the objects in
the system start life with the privileges recorded in pg_init_privs (as
they always were for initdb'd objects but now, by the time we reach the
point where we are issuing the GRANTs and REVOKEs for the extension
objects, those are as well).

With all of these changes to the ACL extension bits of the queries, I
pulled those out into a single buildACLQueries() function instead of
repeating the more-or-less-the-same query fragments inside of every
get*() routine in pg_dump. That refactoring really cleaned up the
pg_dump changes from that patch, in my view.

I also rebased the patch and dealt with the fallout from other recent
changes which have gone into the tree.

I'll be doing more testing, review and clean-up (there are some
whitespace only changes in the later patches that really should be
included in the earlier patches where the code was actually changed)
tonight with plans to push this tomorrow night.

Thanks!

Stephen

Attachment Content-Type Size
catalog_acls_v7.patch text/x-diff 238.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2016-04-05 22:50:14 Materialized views vs. primary keys
Previous Message Alvaro Herrera 2016-04-05 21:45:58 Re: dealing with extension dependencies that aren't quite 'e'