Re: AW: AW: Proposal for enhancements of privilege system
От | Tom Lane |
---|---|
Тема | Re: AW: AW: Proposal for enhancements of privilege system |
Дата | |
Msg-id | 6434.960144460@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: AW: AW: Proposal for enhancements of privilege system ("Zeugswetter Andreas" <andreas.zeugswetter@telecom.at>) |
Ответы |
Re: AW: AW: Proposal for enhancements of privilege system
|
Список | pgsql-hackers |
"Zeugswetter Andreas" <andreas.zeugswetter@telecom.at> writes: >> 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. I tend to agree with Andreas on this: having a separate tuple for each individual kind of access right will consume an unreasonable amount of space --- both on disk and in the syscache, if a cache is used for this table. (In the cache, that translates to entries not living very long before they fall off the LRU list.) regards, tom lane
В списке pgsql-hackers по дате отправления: