From: Stephen Frost <sfrost@snowman.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: 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 15:07:30 -0400
Message-ID: <20190621190730.GS2480@tamriel.snowman.net> (raw)
In-Reply-To: <26419.1561143177@sss.pgh.pa.us>
References: <8b00ea5e-28a7-88ba-e848-21528b632354@2ndquadrant.com>
<CA+TgmoZfJ1Y9Zrcit9zQVTSaPugCAo=UXC8b1URJcFsqNVoxqA@mail.gmail.com>
<20274.1561134523@sss.pgh.pa.us>
<20190621165855.GP2480@tamriel.snowman.net>
<26419.1561143177@sss.pgh.pa.us>
Greetings,
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> So there's certainly some fraction of these cases where we could have
> avoided doing manual catalog updates by expending work on some ALTER
> command instead. But I don't see much reason to think that we could,
> or should try to, insist that every such case be done that way. The
> cost/benefit ratio is not there in some cases, and in others, exposing
> a DDL command to do it would just be providing easier access to
> something that's fundamentally unsafe anyway.
In the cases where we can do better by providing a DDL command, it's
certainly my opinion that we should go that route. I don't think we
should allow something that's fundamentally unsafe in that way- for
those cases though, how is the extension script making it 'safe'? If it
simply is hoping, well, that smells like a bug, and we probably should
try to avoid having that in our extensions as folks do like to copy
them.
When it comes to cases that fundamentally are one-off's and that we
don't think really deserve a proper DDL command, then I'd say we make
the extensions set the flag. At least then it's clear "hey, we had to
do something really grotty here, maybe don't copy this into your new
extension, or don't use this method." We should also un-set the flag
after.
> The change-proargtypes example actually brings up a larger point:
> exactly how is, say, screwing with the contents of the pg_class
> row for a system catalog any safer than doing "DDL" on the catalog?
> I don't think we should fool ourselves that the one thing is
> inherently safer than the other.
I don't believe one to be safer than the other...
> In none of these cases are we ever going to be able to say "that's
> generically safe", or at least if we try, we're going to find that
> distinguishing safe cases from unsafe requires unreasonable amounts
> of effort. I don't think it's a productive thing to spend time on.
> I don't mind having two separate "allow_system_table_ddl" and
> "allow_system_table_dml" flags, because it's easy to tell what each
> of those is supposed to enforce.
Which implies that it doesn't make sense to have two different flags
for it.
> But I'm going to run away screaming
> from any proposal to invent "allow_safe_system_table_dml". It's a
> recipe for infinite security bugs and it's just not worth it.
Yeah, I'm not really a fan of that either.
Thanks,
Stephen
Attachments:
signature.asc (application/pgp-signature, 818B) download
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: sfrost@snowman.net, tgl@sss.pgh.pa.us, robertmhaas@gmail.com, peter.eisentraut@2ndquadrant.com
Subject: Re: allow_system_table_mods stuff
In-Reply-To: <20190621190730.GS2480@tamriel.snowman.net>
* 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