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