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 <[EMAIL PROTECTED]>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
