Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)

We have had discussion on whether we want one or two security columns; 
there have been comments on both sides.

Have we decided if we are going to use some type of integer on every row
that points to a pg_security row or put the value right in the row?

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 am unsure how an insert into a 'security_context' column would
automatically insert into pg_security however.  I am also unclear how
COPY would work.

Also, having the per-row value always be present in the row and
controlled by the bitmask seems ideal;  it avoids having to add a CREATE
TABLE option.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +