On Tue, 2008-11-18 at 13:10 +0900, KaiGai Kohei wrote:
> 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 don't think it is small enough 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.
*Maybe* if you view my request this way:
If a table is defined such that all of its tuples have an identical
security-context then we can optimise away the additional field when
storing tuples.
That might help, it might not. Just trying to help us think of different
ways to allow this within the main server variant.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
