> If we use some type of integer, I suggest using this structure for
> pg_security:
>
> CREATE TABLE pg_security(
> relid oid,
> secid int2,
> secacl aclitem[],
> secext TEXT
> );
>
> This allows the per-row value to be a simple int2. It also improves
> maintenance because rows are associated only with a specific table;
> unused values can then be removed more easily. And it allows both
> secacl and secext security to be specified.
I do not expect that the number of unique combinations of "rights"
strongly varies between the tables. Thus I think creating pg_security rows per
table
would vastly increase the size of pg_security.
The expected size of pg_security is small in the current implementation.
Example: security_context = "top_secret_t"
With above schema you need one row in pg_security for each table that has
"top_secret_t" rows.
The current implementation only needs one row for this, which is imho better.
CREATE TABLE pg_security(
secid serial,
secacl aclitem[],
secext TEXT
);
May be ok, but I am with KaiGai, that it is not obvious how to update the
security context syntactically when using 2 subsystems simultaneously.
But using, restricting and selecting is easy.
Andreas
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
