Re: Updates of SE-PostgreSQL 8.4devel patches (r1268) - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)
Date
Msg-id 200812111838.57436.peter_e@gmx.net
Whole thread Raw
In response to Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)  (KaiGai Kohei <kaigai@kaigai.gr.jp>)
Responses Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
List pgsql-hackers
On Thursday 11 December 2008 18:24:54 KaiGai Kohei wrote:
> Peter Eisentraut wrote:
> > On Thursday 11 December 2008 17:09:25 Tom Lane wrote:
> >> I think there should be only *one* underlying column and that it should
> >> be manipulable by either SQL commands or selinux.  Otherwise you're
> >> making a lie of the primary argument for having the SQL feature at all.
> >
> > Well, an SQL-manipulated row security column will probably have a content
> > like
> >
> >     {joe=rw/bob,staff=r/bob}
> >
> > An SELinux-aware row security column will probably have a content like
> >
> >    blah_t:foo_t:quux_t
> >
> > And a Solaris TX-aware security column will probably have a content like
> >
> >    Classified
> >
> > How can we stick all of these in the same column at the same time?
>
> To choose it on compile-time option is the most simple approach.

As mentioned before, compile-time options to choose between these variants in 
a mutually exlusive manner is not acceptable.

Plus, using two of these together, or even three, is certainly useful and 
reasonable in some uses.


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: WIP: default values for function parameters
Next
From: Alvaro Herrera
Date:
Subject: Re: Refactoring SearchSysCache + HeapTupleIsValid