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. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs