On Tue, 29 Feb 2000, Peter Eisentraut wrote:
> On Tue, 29 Feb 2000, Karel Zak - Zakkr wrote:
>
> > My acl idea:
>
> > reloid | user_insert | group_insert | user_delete ..........etc
> > ---------------------------------------------------------
> > 12345 | {"karel", "peter"} | {"group1"} | {"karel"} ..........etc
>
> This still has arrays. (shudder) Try getting the information 'Does Peter
> have access to x?' out of that. I was thinking along the lines of
As I say: we can use oid or string with oids instead array.
Example
reloid | user_insert | group_insert |--------------------------------------12345 | "1111,2222" | "545454" |
.. parse these strings a easy and 'Does Peter have access to x?' is realy
simple.
>
> create table pg_privilege/pg_acl/? (
> objoid oid, -- not only reloid, but types, functions, etc. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
yes, yes, yes ! (the oracle allow grant priv. to 25(!) different features)
> userid int,
If I understend you, you want save to one line information about one
user only (?), if yes this table will huge (sum(object) * sum(users)),
but probably fastly (because it not needs parse any array or string).
Hmm, perhaps it is not bad idea. What say the other?
> privilege char, -- maybe 'U' update, 'I' insert, etc.
I really not sure if is good still create this monolithic string,
why not use one (bool) column for update one for insert ..etc?
It is fastly and easy (a string needs parse, etc).
> grant_option bool
> )
It is goods if you agree with separate acl table :-)
> To be extended to cover column access as well. (Might have to be yet
> another table.) Mathematically, this will be slower (especially since you
> can't use SysCache on composite keys(???)) but similar schemas are
> employed throughout by triggers etc.
Yes, a speed will problem, it must be cached (in an separate acl cache?),
or after (connection) start create a temp table with acl for a current user
and with relevant information only. Karel
