On Tue, 29 Feb 2000, Thomas Lockhart wrote:
> > plan make changes to acl/account code it must be non-isolate change (it
> > must include user-profiles ..etc). (IMO of course :-)
>
> While I'm thinking about it...
>
> The current acl storage scheme flattens the acl info into a single
> string, with a special character ("=" as I recall) to delimit the
> user/group name from the permissions. But by quoting the user name, it
> is possible to create a user name which contains an equals sign,
> screwing up the acl handling.
>
> If you are redoing the acls, a good first step is to fix this, perhaps
> by recoding the acl field into a structure with at least two fields
> for username and permissions.
Yes. And..the current schema (acl in pg_class) is not relation schema, in
the pg_class is username not user's oid...ect. Is possible create it as
relation? (Example, in pg_group we haven't username, we use oid here.)
My acl idea:
Why not create specific pg_acl table and split a current monolitic
acl string to more columns? Example:
Columns in pg_acl table:
reloid (oid) - relation (table) oiduser_insert (text[]) - privilege for users for insert - in
textarray is {"username1","username2"... } (or use user's oid instead username)
group_insert - simular as previous, but for groupuser_delete - ....etc....
example:
SELECT * from pg_acl;
reloid | user_insert | group_insert | user_delete ..........etc
---------------------------------------------------------
12345 | {"karel", "peter"} | {"group1"} | {"karel"} ..........etc
Is it bad idea? (It never needs any specific acl string parser, take
informatios from this table is very simple and very standard
"tuple-operation".) Yes, it is a little "talkative", but if instead
user/group name we use oid, it will right and nice.
...as I said: is the current acl/account schema good?
Karel
