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
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 |