Date: Fri, 21 Jun 2019 15:07:30 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>,
	Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
	pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: allow_system_table_mods stuff
Message-ID: <20190621190730.GS2480@tamriel.snowman.net>
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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="JOdSqRa1q7Th5Ot+"
Content-Disposition: inline
In-Reply-To: <26419.1561143177@sss.pgh.pa.us>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk


--JOdSqRa1q7Th5Ot+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

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

--JOdSqRa1q7Th5Ot+
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJdDSryAAoJEO1sijiDR2RV2KgP/2TqtBSw/bXzFvj+j9OEz7B1
Sh5RSBdrTr2+3vz+Ij8tacuR6+UC5TB3c7B5O5iWEVA19eUkomNcHSdrGF6F81TC
K9sbSFa7NjC9YPb1YgguOuF/0+M+cIZCJCYlfCVfLGYLtpiR9kW16R4GGYXnEvpB
/NmrNJjufCZ50TNRuXIqTUfjcvv0Wxb1VpL82Hh/d5phcjVKP/V+5r5J5TPLBHm9
25VZb++oswBGzlk0ls8WHGCUj+JUuaM2xFVNPsHjKbUKH+pXIn25KqrrMo9tXQrR
gZ7uOog/2My/R9Nas5+BS3k+yyFyhyv57Y/+Y6VdRDJqCL6Xju9UHLMeltOxJEFk
CRQxC7F6MikT8FTgyKBbITAq2VvOBzkbLHGqgYK0obK66YgOyYjIgQPfaAYI1jtR
YhIiN+ExOQRO9PJjKbkP7WJseGue3UYXGL6W2jqPZlUIfS8vouFNkJb0o6IWQkjF
P5TGT3LEKiUGtuMwkVDvfLY0S1VudS0ODeF9zKQbANMREd/pQiUK1mBn/beSre3l
8XbKmbfMYYf1dbr9m1shbtoJVZfc3I3bUwLZadXyct9ez7Nzv1oHUUrViEgfJlu6
zdEaIetjoPEOFcHGPasDBZ9XSmIU3wwXQyfs59JetjiDc4Zfy6P5q2rd/EO2ENWI
OSzN8xMsDd8KPPaPvMev
=pc/O
-----END PGP SIGNATURE-----

--JOdSqRa1q7Th5Ot+--