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? -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
