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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers