On Fri, Jun 4, 2010 at 4:53 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> Personally, I think it would be better to put some work into making >> allow_system_table_mods a little less simple-minded. Right now, >> !allow_system_table_mods prohibits you from doing perfectly sensible >> things (as in the OP's original example) yet still allows you to do >> things that are totally nuts (like DELETE FROM pg_class, which causes >> every subsequent connection attempt for that database to panic). >> Perfection may be too much to ask for but I'd take "modest >> improvement"... > > Nope, that is the wrong viewpoint entirely. allow_system_table_mods > is intended to prevent you from modifying the *structure* of the > system catalogs, which is fairly critical because the backend C code > tends to depend on that. Modifying the *content* of the catalogs > is another matter, and in fact we let any superuser do that without > having set allow_system_table_mods. There is no practical way to > distinguish a benign catalog-content change from a disastrous one, > so we don't try. > > It's possible that reloptions is a special case and we should treat it > as being more nearly in the content than structure category. Not sure.
The backend C code also depends on the critical system indexes being present in the system catalogs, yet we still allow them to be deleted. Is there really a use case for users fiddling with pg_proc, pg_class, etc. directly? 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
