Re: [HACKERS] Re: [PATCHES] NO-CREATE-TABLE and NO-LOCK-TABLE

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