Re: AW: AW: Proposal for enhancements of privilege system

From: "Zeugswetter Andreas" <andreas(dot)zeugswetter(at)telecom(dot)at>
To: "Peter Eisentraut" <peter_e(at)gmx(dot)net>
Cc: "'PostgreSQL Development'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: AW: AW: Proposal for enhancements of privilege system
Date: 2000-06-04 11:33:53
Message-ID: 008801bfce1c$becd6080$ef23080a@sd.spardat.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zeugswetter Andreas 2000-06-04 12:57:50 Re: New warning code for missing FROM relations
Previous Message Denis Perchine 2000-06-04 10:06:05 Problem upgrading from 7.0 to 7.0.1