Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)
От | Zeugswetter Andreas OSB sIT |
---|---|
Тема | Re: Updates of SE-PostgreSQL 8.4devel patches (r1268) |
Дата | |
Msg-id | 6DAFE8F5425AB84DB3FCA4537D829A561CEA715FCF@M0164.s-mxs.net обсуждение исходный текст |
Ответ на | Re: Updates of SE-PostgreSQL 8.4devel patches (r1268) (Bruce Momjian <bruce@momjian.us>) |
Список | pgsql-hackers |
> 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
В списке pgsql-hackers по дате отправления: