Re: allow_system_table_mods stuff

From: Chapman Flack <chap(at)anastigmatix(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: allow_system_table_mods stuff
Date: 2019-06-21 20:43:33
Message-ID: fd967f80-51ba-3d19-03c0-9fe778699895@anastigmatix.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 6/21/19 4:37 PM, Tom Lane wrote:
> 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.

I was having second thoughts too, like maybe to tweak ALTER EXTENSION
UPDATE to unconditionally force the flag on before the update script and
reset it after, but warn if it is actually still set at the reset-after
point.

Extension maintainers could then make the warning go away by releasing
versions where the update scripts contain an explicit RESET (at the very
top, if they do nothing fancy), or a(n initially redundant) SET at the
top and RESET at the bottom. No new control file syntax.

Regards,
-Chap

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-06-21 21:02:38 Re: allow_system_table_mods stuff
Previous Message Tom Lane 2019-06-21 20:37:16 Re: allow_system_table_mods stuff