Re: No toast table for pg_shseclabel but for pg_seclabel

* Andres Freund (andres(at)2ndquadrant(dot)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 <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > >
> > > Bruce Momjian <bruce(at)momjian(dot)us> 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 done anything about it ...
> > >
> >
> > If the final decision is get rid the toast table for pg_seclabel and as
> > I've time then I did it.
>
> 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
provider with multiple rows (which is fine by itself), and so that means
security providers with multiple overlapping labels for the same object
need to combine them together and store them together. While I agree
that individual labels don't tend to get very long, when you combine
overlapping ones, they could get long enough to need toasting.

Admittedly, you could complicate the system by defining those labels as
new labels, but we are likely working with an external authorization
system and it's a lot less trouble to attach multiple labels to the
given object than to ask everyone else to change because PG ran out of
room in the text column because it can't TOAST it..

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.

Thanks,

Stephen