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) oid
	user_insert	(text[]) - privilege for users for insert
				 - in text array is 
			{"username1","username2"... 	}
			(or use user's oid instead username)   

	group_insert	- simular as previous, but for group
	user_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