> > We already have an optional OID system column that can be specified
> > during table creation (WITH OIDS). We could have another optional oid
> > column (WITH ROW SECURITY) called security_context which would store the
> > oid of the role that can see the row; if the oid is zero (InvalidOid),
A role alone is not sufficient. It needs to be the proposed mapping to pg_security.
> > anyone can see it. SE-PostgreSQL would default to WITH ROW SECURITY and
> > use the oid to look up strings in pg_security.
>
> The above explanation is not correct, as Tom mentioned.
> The security system column is declared as TEXT type, however, every tuple
> has a Oid value to indicate pg_security system catalog. It enables to
> prevent waste of storage. When user tries to read the system column,
> it is translated from Oid to text representation.
Imho the important points Bruce wanted to make are:
1. there is only one extra oid storage column per row (regardless whether it is translated to text upon select)
thisis already the case in the patch.
2. the column(s) are system columns, so they do not show up in "select *"
I think having access to the oid directly could be beneficial to performance.
e.g. a smart client could cache pg_security and map the oid's to text locally
instead of transferring the quite verbose text representation for every row.
That may be mute, because showing the security_context definitely sounds more
like an admin kind of functionality.
Traditionally the column would probably be oid and sql would need to cast it for
the text representation (e.g. security_context::regsecurity).
Andreas