Re: pg_dump dump catalog ACLs - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: pg_dump dump catalog ACLs
Date
Msg-id 20160405215018.GY10850@tamriel.snowman.net
Whole thread Raw
In response to Re: pg_dump dump catalog ACLs  (Stephen Frost <sfrost@snowman.net>)
Responses Re: pg_dump dump catalog ACLs  (Noah Misch <noah@leadboat.com>)
List 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

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: dealing with extension dependencies that aren't quite 'e'
Next
From: David Fetter
Date:
Subject: Materialized views vs. primary keys