Robert Haas <robertmhaas@gmail.com> writes:
> I kinda feel like we should prohibit DML on system catalogs, even by
> superusers, unless you press the big red button that says "I am
> definitely sure that I know what I'm doing."
Keep in mind that DML-on-system-catalogs is unfortunately a really
standard hack in extension upgrade scripts. (If memory serves,
some of our contrib scripts do that, and we've certainly told third
parties that it's the only way out of some box or other.) I don't
think we can just shut it off. What you seem to be proposing is to
allow it only after
SET allow_system_table_mods = on;
which would be all right except that an extension script containing
such a command will fail outright in existing releases. I think we
need to be friendlier than that to extension authors who are, for the
most part, trying to work around some deficiency of ours not theirs.
I'm not saying that DML-off-by-default is a bad goal to work toward;
I'm just saying "mind the collateral damage".
> A related issue is that alter_system_table_mods prohibits both stuff
> that's probably not going to cause any big problem and stuff that is
> almost guaranteed to make the system permanently unusable - e.g. you
> could 'SET STORAGE' on a system catalog column, which is really pretty
> innocuous, or you could change the oid column of pg_database to a
> varlena type, which is guaranteed to destroy the universe. Here
> again, maybe some operations should be more protected than others, or
> maybe the relatively safe things just shouldn't be subject to
> allow_system_table_mods at all.
Meh. It doesn't really seem to me that distinguishing these cases
is a productive use of code space or maintenance effort. Superusers
are assumed to know what they're doing, and most especially so if
they've hit the big red button.
regards, tom lane
