Re: pg_dump dump catalog ACLs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_dump dump catalog ACLs
Date: 2016-03-01 16:00:53
Message-ID: 12526.1456848053@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Joe Conway <mail(at)joeconway(dot)com> writes:
> Would it be a terrible idea to add some attribute to ACLs which can be
> used to indicate they should not be dumped (and supporting syntax)?

Yes, we'd need some way to mark non-null ACLs as being "built-in
defaults". I do not see the need to have SQL syntax supporting that
though.

Actually, wouldn't you need to mark individual aclitems as built-in
or not? Consider a situation where we have some function foo() that
by default has EXECUTE permission granted to some built-in "pg_admin"
role. If a given installation then also grants EXECUTE to "joe",
what you really want to have happen is for pg_dump to dump only the
grant to "joe". Mentioning pg_admin's grant would tie the dump to
a particular major PG version's idea of what the built-in roles are,
which is what I'm arguing we need to avoid.

I guess this could also be addressed by having two separate aclitem[]
columns, one that is expected to be frozen after initdb and one for
user-added grants.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-03-01 16:03:50 Re: The plan for FDW-based sharding
Previous Message Robert Haas 2016-03-01 16:00:37 Re: PROPOSAL: Fast temporary tables