but the auto-creation of pg_security rows does make this problematic. regproc works because it only supports pre-created pg_proc rows.
Yes, the security label has a different characteristic at the point.
Can we support two data types, one for read-only and another for possible creation? That is not going to work for a query like SELECT * FROM x WHERE col != 'valid_but_new_security_label'::regseclabel; because the cast would fail if the pg_security row doesn't exist, but the query itself perhaps might succeed and return rows.
It has a same matter. If user cast a text into the type of possible creation, it can cause an unnecessary insertion.
Can we require joins to use pg_security directly? I wish I could think of some magic that indicated the pg_security row should be created.
We should not allow users to join them directly, and should not expose what identifier is used internally, because some of ISO/IEC15408 has requirements to export/import user data with meaningful security labels. The numeric security identifier is just an internal usage. Here is one another idea. How do you think asymmetric input/output handlers? At first, I have to introduce the current implementation. It can receives user input values as TEXT or ACLITEM[], ant these are fetched at fetchWritableSystemAttribute() on execMain.c. Please note that they have no side-effect on the prior stage. Then, it invokes rowaclSecurityAclToSid() or pgaceSecurityLabelToSid() to translate the values into security identifier. These functions can insert a new tuple into pg_security, if not found. Then, the translated security identifiers are set on the HeapTupleHeader using HeapTupleSetRowAcl() or HeapTupleSetSecLabel(). If the input handler is asymmetric, it can handle the given user input as a TEXT or ACLITEM[], and can deliver them fetchWritableSystemAttribute() as is. But asymmetric output handler can translate given security identifier into proper user visible data. However, I don't think it is a fair enough solution. :( The current implementation seems to me better. Thanks, -- KaiGai Kohei <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers