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