On March 22, 2015 3:15:07 AM GMT+01:00, Bruce Momjian wrote:
>On Thu, Mar 19, 2015 at 11:50:36AM -0400, Bruce Momjian wrote:
>> > Then there's the other discussion about using the security labels
>> > structure for more than just security labels, which could end up
>with a
>> > lot of other use-ca
On Thu, Mar 19, 2015 at 11:50:36AM -0400, Bruce Momjian wrote:
> > Then there's the other discussion about using the security labels
> > structure for more than just security labels, which could end up with a
> > lot of other use-cases where the "label" is even larger.
>
> OK, the attached patch a
On Sat, Oct 11, 2014 at 06:01:58PM -0400, Stephen Frost wrote:
> > I still think this the wrong direction. I really fail to see why we want
> > to restrict security policies to some rather small size.
>
> I agree with this.
>
> There's no ability to store multiple labels for the same object and
>
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2014-10-11 18:19:05 -0300, Fabrízio de Royes Mello wrote:
> > On Sat, Oct 11, 2014 at 5:40 PM, Tom Lane wrote:
> > >
> > > Bruce Momjian writes:
> > > > On Fri, Jul 4, 2014 at 10:53:15AM -0400, Tom Lane wrote:
> > > >> So maybe we should get r
On 2014-10-11 18:19:05 -0300, Fabrízio de Royes Mello wrote:
> On Sat, Oct 11, 2014 at 5:40 PM, Tom Lane wrote:
> >
> > Bruce Momjian writes:
> > > On Fri, Jul 4, 2014 at 10:53:15AM -0400, Tom Lane wrote:
> > >> So maybe we should get rid of the toast table for pg_seclabel. One
> less
> > >> ca
On Sat, Oct 11, 2014 at 5:40 PM, Tom Lane wrote:
>
> Bruce Momjian writes:
> > On Fri, Jul 4, 2014 at 10:53:15AM -0400, Tom Lane wrote:
> >> So maybe we should get rid of the toast table for pg_seclabel. One
less
> >> catalog table for a feature that hardly anyone is using seems like a
fine
> >
Bruce Momjian writes:
> On Fri, Jul 4, 2014 at 10:53:15AM -0400, Tom Lane wrote:
>> So maybe we should get rid of the toast table for pg_seclabel. One less
>> catalog table for a feature that hardly anyone is using seems like a fine
>> idea to me ...
> Is this still an open item?
I haven't don
On Fri, Jul 4, 2014 at 10:53:15AM -0400, Tom Lane wrote:
> Kohei KaiGai writes:
> > Here is no other reason than what Alvaro mentioned in the upthread.
> > We intended to store security label of SELinux (less than 100bytes at most),
> > so I didn't think it leads any problem actually.
>
> > On t
Kohei KaiGai writes:
> Here is no other reason than what Alvaro mentioned in the upthread.
> We intended to store security label of SELinux (less than 100bytes at most),
> so I didn't think it leads any problem actually.
> On the other hands, pg_seclabel was merged in another development cycle.
>
Here is no other reason than what Alvaro mentioned in the upthread.
We intended to store security label of SELinux (less than 100bytes at most),
so I didn't think it leads any problem actually.
On the other hands, pg_seclabel was merged in another development cycle.
We didn't have deep discussion
On 2014-07-04 11:50:17 +0200, Andres Freund wrote:
> Hi,
>
> postgres=# SELECT oid::regclass, reltoastrelid FROM pg_class WHERE relname IN
> ('pg_seclabel', 'pg_shseclabel');
> oid | reltoastrelid
> ---+---
> pg_seclabel | 3598
> pg_shseclabel |
Hi,
postgres=# SELECT oid::regclass, reltoastrelid FROM pg_class WHERE relname IN
('pg_seclabel', 'pg_shseclabel');
oid | reltoastrelid
---+---
pg_seclabel | 3598
pg_shseclabel | 0
(2 rows)
Isn't that a somewhat odd choice? Why do we as
12 matches
Mail list logo