* 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 <t...@sss.pgh.pa.us> wrote: > > > > > > Bruce Momjian <br...@momjian.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
signature.asc
Description: Digital signature