From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: allow_system_table_mods stuff
Date: Fri, 21 Jun 2019 12:28:43 -0400
Message-ID: <20274.1561134523@sss.pgh.pa.us> (raw)
In-Reply-To: <CA+TgmoZfJ1Y9Zrcit9zQVTSaPugCAo=UXC8b1URJcFsqNVoxqA@mail.gmail.com>
References: <8b00ea5e-28a7-88ba-e848-21528b632354@2ndquadrant.com>
<CA+TgmoZfJ1Y9Zrcit9zQVTSaPugCAo=UXC8b1URJcFsqNVoxqA@mail.gmail.com>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, robertmhaas@gmail.com, peter.eisentraut@2ndquadrant.com
Subject: Re: allow_system_table_mods stuff
In-Reply-To: <20274.1561134523@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox