On Sun, 2009-06-28 at 14:56 -0400, Tom Lane wrote:
> > I meant for "foo" to be a user. "foo_ro" would be the read-only version,
> > who has a strict subset of foo's permissions.
>
> I see. It seems like rather a complicated (and expensive) mechanism
> for a pretty narrow use-case. It'd only help for the cases where you
> could define your permissions requirements that way. I agree that
> there are some such cases, but I think real-world problems tend to be
> a bit more complicated than that. I fear people would soon want
> exceptions to the "strict subset" rule; and once you put that in,
> the conceptual simplicity disappears, as does the ability to easily
> verify what the set of GRANTs is doing.
As soon as the permissions scheme gets more complicated than what I
suggest, I agree that the user is better off just using GRANTs on a
per-object basis. You could still GRANT directly to the user foo_ro --
for instance if your reporting user needs to join against some other
table -- but that could get complicated if you take it too far.
The users I'm targeting with my idea are:* Users who have a fairly simple set of users and permissions, and who want
asimple picture of the permissions in their system for reassurance/verification.* Users who come from MySQL every
oncein a while, annoyed that we don't support "GRANT ... *" syntax.* Users who are savvy enough to use access control,
butdon't have rigorous procedures for making DDL changes. Some of these users depend on an ORM or similar to make
DDLchanges for them, and this idea gives them a workaround.* Users who don't currently use separate permissions, but
mightstart if it's simpler to do simple things.
Maybe I should shop this idea on -general and see how many people's
problems would actually be solved?
The performance issue is something to consider, but I think it would
just be an extra catalog lookup (for each level), and the users of this
feature would probably be willing to pay that cost.
Regards,Jeff Davis
