Corey,
* Corey Huinker (corey.huinker@gmail.com) wrote:
> I think allowing users to receive and send serialized relacl values (which
> is what I *think* you're asking about here) is only slightly less icky, and
That isn't actually what I was suggesting.
> presents a backward compatibility issue. Those issues go away if the ACL is
> contained in an existing object, or exists only for the life of a
> statement. In which case I think you're suggesting something like this:
Right- an existing 'object'.
What I was suggesting is that we have, for lack of a better word,
'profiles'- which are essentially complete, named, aclitem arrays. That
way, we aren't tying this to an existing object in the system but rather
making it a top-level object on its own, in a manner akin to how the
default privileges system contains acitem arrays which are not
associated with an object.
Consider:
CREATE PROFILE joe_select GRANT SELECT ON TABLES TO joe;
ALTER DEFAULT PRIVILEGES IN SCHEMA joes PROFILE joe_select;
ALTER TABLE joe SET PROFILE joe_select;
etc.
The other question this brings up, as I think I mentioned before, is
this: is this a one-time copy of that 'profile'? What if the profile
is later changed?
For my 2c, I kind of like the idea that an update to the profile would
cause the privileges to be effectivly changed for all objects using that
profile, though that may mean we end up with a different kind of
implementation than what you proposed of just copying the relacl.
Generally speaking, setting a profile should be the purview of the owner
of the object, imv. We would also have to consider if objects can have
both a profile and independently granted accesses. I'm thinking the
answer to that is probably 'yes'.
Thanks!
Stephen
