> > > Ah, that is a good point, that if we have "security column" which is > > > usually null then we are requiring the NULL bitmask.
Yes, I think that would not be optimal, thus I think "WITH SECURITY_CONTEXT" is needed. > I sure wish others were adding ideas to this discussion. One such idea would be, that the security info is already normalized. pg_security has one row for each security_context. It is my understanding, that such a context row may already be a combination of "rights". Thus adding an extra column per subsystem to the user tables may not be required. You could have all info for each security subsystem in the pg_security table. This can eighter be done by having one row in pg_security per subsystem type and oid, or by having a separate column in pg_security per subsystem. The imho difficult part is, that currently selecting "security_context" defaults to mapping the oid to the text representation for selinux. Concern has already been voiced in this regard. Maybe this is another reason to not do automatic mapping, but require a specified conversion for text output. Or is the column name "security_context" and representation a standard ? This is just an idea, since I do not really think actually using more than one security subsystem in parallel will be common. Andreas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
