Zeugswetter Andreas OSB sIT wrote:
>>> 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)
> this is 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).
In most of cases, SE-PostgreSQL does not need to translate the security identifier
into text representation, because it caches the result of access checks between
the client and the recently used "security_context". SE-PostgreSQL can make its
decision refering the internal hash table with the security Oid.
(See, src/backend/security/sepgsql/avc.c)
When user requires to expose "security_context", it is necessary to lookup pg_security
to translate the security Oid into text representation, but I guess it is not frequently.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
