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 <kaigai@ak.jp.nec.com>