From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: What's the point of allow_system_table_mods? |
Date: | 2019-05-10 19:00:18 |
Message-ID: | 12810.1557514818@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> "Andres" == Andres Freund <andres(at)anarazel(dot)de> writes:
> Andres> Why is it so much more dangerous? I've seen plenty of corrupted
> Andres> clusters due to people doing DML against the catalogs. I'm OK
> Andres> with adding separate GUCs for both, if we want to do that, but
> Andres> I do think we shouldn't allow updating the catalogs wthout
> Andres> having having the superuser explicitly opt into that.
> Be aware that a nonzero number of extensions (postgis especially) do
> catalog DML in their install or update scripts.
I believe we've done that in some contrib update scripts, as well.
> While you might well
> think they shouldn't do that, in practice there is usually no viable
> alternative.
In principle, if the thing is SUSET, we could have such extension scripts
set it temporarily. But it would be a compatibility hazard -- a script
with such a SET command in it would fail in older branches.
What exactly is the motivation for changing this now, after 20 years?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2019-05-10 19:16:13 | Re: What's the point of allow_system_table_mods? |
Previous Message | Andrew Gierth | 2019-05-10 18:51:10 | Re: What's the point of allow_system_table_mods? |