On Fri, Feb 4, 2011 at 10:45 PM, Bruce Momjian <br...@momjian.us> wrote: > Tom Lane wrote: >> Robert Haas <robertmh...@gmail.com> writes: >> > Is there really a use case for users fiddling with pg_proc, pg_class, >> > etc. directly? >> >> There's a use case for *superusers* to fiddle with them, yes. >> (Superusers are presumed to be adults.) I think I recommend a quick >> UPDATE on some catalog at least once a month on the lists. >> >> You might care to consider the fact that no modern Unix system prevents >> root from doing rm -rf /, even though that's "obviously" disastrous. >> Yet (stretching the analogy all out of shape) there's no convenient user >> tool for rearranging the contents of all the inodes on a filesystem. >> >> > At any rate, I'd be happy to drop that part of the proposal. It would >> > be a step forward just to permit (even without >> > allow_system_table_mods) those changes which don't alter the structure >> > of the catalog. For ALTER TABLE, the SET STATISTICS, (RE)SET >> > (attribute_option), SET STORAGE, CLUSTER ON, SET WITHOUT CLUSTER, and >> > (RE)SET (reloptions) forms are all things that fall into this >> > category, I believe. >> >> It would be far less work to just drop allow_system_table_mods to SUSET. >> And we wouldn't get questions about which forms of ALTER TABLE require >> it. > > Are we going to make the allow_system_table_mods to SUSET change? Is it > a TODO?
I'd rather not drop it to SUSET. If we're going to make an effort in this area, I'd rather do the work to distinguish the destroy-your-database cases from the ones that are reasonable for an admin to want to do. I wouldn't make it a TODO, though. We have no consensus on what, if anything, is worth doing. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
