> > 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.
>
> That's a valid concern, but unfortunately things aren't that easy. For
> each access right you also have to store what user granted
> that privilege
each new grantor will create a new row.
(thus the primary key needs to be extended: object, grantee, grantor)
In the system cache you will probably want a key of object+grantee
with a merged result over the grantors.
Remember that you can be granted a certain priviledge by more than
one grantor, thus your key was not correct to begin with.
(sorry I didn't realize that earlier)
> and whether it's grantable, and for SELECT also whether it
> includes the
> "hierarchy option" (has to do with table inheritance somehow).
separate priviledge "h"
>
> Say you store all privileges in an array, then you'd either
> need to encode
> all 3 1/2 pieces of information into one single data type and make an
> array thereof (like `array of record privtype; privgrantor;
> privgrantable'), which doesn't really make things easier, or you have
> three arrays per tuple, which makes things worse. Also
> querying arrays is
> painful.
I actually didn't mean real arrays, but e.g. a char(n) where each position
marks a certain priv. e.g. "SU-ID---" = with grant option, "su-id---"
without grant options.
This has the advantage of still beeing human readable and does not waste too
much space.
> So the break-even point for this new scheme is when
> users have on
> average at least 1.4 privileges (78/54) granted to them on one object.
> Considering that such objects as types and functions will in
> any case have
> at most one privilege (USAGE or EXECUTE, resp.), that there
> are groups (or
> roles), that column level privileges will probably tend to have sparse
> tuples of this kind, and that object owners are short-circuited in any
> case, then it is not at all clear whether that figure will be reached.
Well I think it is not for us to decide, how the security system is used
by the users. It has to be designed to allow heavy use, and still be
efficient.
Andreas