Re: AW: AW: Proposal for enhancements of privilege system - Mailing list pgsql-hackers

From Zeugswetter Andreas
Subject Re: AW: AW: Proposal for enhancements of privilege system
Date
Msg-id 008801bfce1c$becd6080$ef23080a@sd.spardat.at
Whole thread Raw
In response to Re: AW: AW: Proposal for enhancements of privilege system  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: AW: AW: Proposal for enhancements of privilege system
List pgsql-hackers
> > Again Hmm ? Are you going to do select * from <authtable> where pri="select"
> > or some such ? Usually you look up a users rights for a specific table,
> > and that needs to be fast.
> 
> Exactly, that's why I have to do it like this. To interface a system
> catalog to the shared cache you need a primary key, which would be
> (object, user, action) in my proposal. With that setup I can easily make
> queries of the sort "does user X have select right on table Y" as fast as
> possible, no slower than, say, looking up an attribute definition in
> pg_attribute.

Ok, I see that you will somtimes want to do a select like that, only I do 
not see the reason why this has to be the primary target for speed.
Remember that for each row in the db you have >30 bytes of overhead
(I forgot the exact number) plus table_oid + user_oid thus if a user has 
all permissions on a table, that will take 300 bytes.
I also think that a key of object + {user|group} is imho selective enough,
you don't want a key whose only info is a boolean.

Andreas



pgsql-hackers by date:

Previous
From: Denis Perchine
Date:
Subject: Problem upgrading from 7.0 to 7.0.1
Next
From: "Zeugswetter Andreas"
Date:
Subject: Re: New warning code for missing FROM relations