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
> 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.
OK, the attached patch adds a TOAST table to the shared table
pg_shseclabel for use with long labels. The new query output shows the
shared and non-shared seclabel tables now both have TOAST tables:
test=> SELECT oid::regclass, reltoastrelid FROM pg_class WHERE relname IN ('pg_seclabel', 'pg_shseclabel');
oid | reltoastrelid
---------------+---------------
pg_seclabel | 3598
pg_shseclabel | 4060
(2 rows)
Previously pg_shseclabel was zero.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +