From: Tom Lane <tgl@sss.pgh.pa.us>
To: Chapman Flack <chap@anastigmatix.net>
Cc: Stephen Frost <sfrost@snowman.net>
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 16:37:16 -0400
Message-ID: <30500.1561149436@sss.pgh.pa.us> (raw)
In-Reply-To: <371ecfe3-7ab2-07e3-2e1a-c45a7bdbfb54@anastigmatix.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>
<20190621190730.GS2480@tamriel.snowman.net>
<371ecfe3-7ab2-07e3-2e1a-c45a7bdbfb54@anastigmatix.net>
Chapman Flack <chap@anastigmatix.net> writes:
> I'd be leery of collateral damage from that to extension update scripts
> in extension releases currently in the wild.
Yeah, that's my primary concern here.
> Maybe there should be a new extension control file setting
> needs_system_table_mods = (boolean)
> which means what it says if it's there, but if an ALTER EXTENSION
> UPDATE sees a control file that lacks the setting, assume true
> (with a warning?).
I think that having a SET command in the update script is the way to go;
for one thing it simplifies testing the script by just sourcing it,
and for another it defaults to no-special-privileges which is the
right default. Also, non-backward-compatible control files aren't
any nicer than non-backward-compatible script files.
We do have to get past the compatibility issue though. My thought was
that for a period of N years we could force allow_system_table_dml = on
while running extension scripts, and then cease doing so. This would
give extension authors a reasonable window in which their scripts would
work in either old or new backends. At some point in that time they'd
probably have occasion to make other changes that render their scripts
not backwards compatible, at which point they can insert "SET
allow_system_table_dml = on" so that the script keeps working when we
remove the compatibility hack.
(Of course, we have an awful track record about actually doing things
N years after we said we would, but doesn't anybody around here have
a calendar app?)
This line of thought leads to the conclusion that we do want
separate "allow_system_table_dml" and "allow_system_table_ddl"
bools. Otherwise, the backwards-compatibility hack would need
to turn on a level of unsafety that extension scripts have *not*
had before and surely shouldn't have by default.
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, chap@anastigmatix.net, sfrost@snowman.net, robertmhaas@gmail.com, peter.eisentraut@2ndquadrant.com
Subject: Re: allow_system_table_mods stuff
In-Reply-To: <30500.1561149436@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