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 по дате отправления: