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