KaiGai Kohei wrote: > Simon Riggs wrote: >>> The other is an issue on implementation. Even if row-level security is >>> disabled, tuples within pg_class, pg_attribute, pg_proc and pg_largeobject >>> has to hold its security context, because it means the security context of >>> tables, columns, procedure and largeobjects. >>> However, the length of a tuple is computed at heap_form_tuple(), and its >>> arguments don't contains the object id of relation. Thus, we cannot make >>> a decision whether the newly created tuple should have a security field, or >>> not. The heap_form_tuple() is invoked from 60 of functions. It might be >>> possible to change all the argument list to deliver relation id. But it >>> seems to me excess updates for the purpose. >> WITH OIDS seems to work well without problem. Why is this different? > > It is not a problem, but things which take a decision. > > The heap_form_tuple() makes a new tuple according to the given > TupleDesc which has a bool variable of "tdhasoid". > This structure can be initialized at various functions. For example, > 47 of functions invoke CreateTemplateTupleDesc() which requires an > argument of "bool hasoid". > If we follow the way of WITH OIDS, it will be necessary to modify > the declaration and 47 of invocations, at least. > > I don't think your suggestion is a bad idea, except for the number > of modification on the core implementation.
In addition, I want you to make clear the priority of the facility. We can disable row-level access control factually with uniformed security context which allows client any kind of accesses. In this case, all tuples shares a single text representation, so the size of external text representation is enough small to ignore. I guess you concerned the per-tuple security attribute because it has 1:1 mapped text representation on pg_security. However, it is incorrect. I don't think we should give high priority for the feature to kill per-tuple security attribute now. Thanks, -- OSS Platform Development Division, NEC 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
