Re: [HACKERS] No toast table for pg_shseclabel but for pg_seclabel

2015-03-22 Thread Andres Freund
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

Re: [HACKERS] No toast table for pg_shseclabel but for pg_seclabel

2015-03-21 Thread Bruce Momjian
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

Re: [HACKERS] No toast table for pg_shseclabel but for pg_seclabel

2015-03-19 Thread Bruce Momjian
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 >

Re: [HACKERS] No toast table for pg_shseclabel but for pg_seclabel

2014-10-11 Thread Stephen Frost
* 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

Re: [HACKERS] No toast table for pg_shseclabel but for pg_seclabel

2014-10-11 Thread Andres Freund
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

Re: [HACKERS] No toast table for pg_shseclabel but for pg_seclabel

2014-10-11 Thread Fabrízio de Royes Mello
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 > >

Re: [HACKERS] No toast table for pg_shseclabel but for pg_seclabel

2014-10-11 Thread Tom Lane
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

Re: [HACKERS] No toast table for pg_shseclabel but for pg_seclabel

2014-10-11 Thread Bruce Momjian
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

Re: [HACKERS] No toast table for pg_shseclabel but for pg_seclabel

2014-07-04 Thread Tom Lane
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. >

Re: [HACKERS] No toast table for pg_shseclabel but for pg_seclabel

2014-07-04 Thread Kohei KaiGai
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

Re: [HACKERS] No toast table for pg_shseclabel but for pg_seclabel

2014-07-04 Thread Andres Freund
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 |

[HACKERS] No toast table for pg_shseclabel but for pg_seclabel

2014-07-04 Thread Andres Freund
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