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 about necessity of toast table of pg_seclabel. I added its toast table mechanically. It never means we need toast table for local object but don't need it for shared database object. Thanks, 2014-07-04 19:11 GMT+09:00 Andres Freund <and...@2ndquadrant.com>: > 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 | 0 >> (2 rows) >> >> Isn't that a somewhat odd choice? Why do we assume that there cannot be >> lengthy seclabels on shared objects? Granted, most shared objects aren't >> candidates for large amounts of data, but both users and databases don't >> seem to fall into that category. > > Hm. It seems they were explicitly removed around > http://archives.postgresql.org/message-id/1309888389-sup-3853%40alvh.no-ip.org > > I don't understand the reasoning there. There's a toast table for > non-shared objects. Why would we expect less data for the shared ones, > even though they're pretty basic objects and more likely to be used to > store policies and such? > > Greetings, > > Andres Freund > > -- > Andres Freund http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services -- KaiGai Kohei <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers