Re: superuser unable to modify settings of a system table
От | Tom Lane |
---|---|
Тема | Re: superuser unable to modify settings of a system table |
Дата | |
Msg-id | 23774.1275686014@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: superuser unable to modify settings of a system table (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: superuser unable to modify settings of a system table
Re: superuser unable to modify settings of a system table |
Список | pgsql-bugs |
Robert Haas <robertmhaas@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
В списке pgsql-bugs по дате отправления: