On 2019-11-28 17:11, Tom Lane wrote:
I read through the patch set and have just one quibble: in the
proposed new docs,
+Allows modification of the structure of system tables as well as
+certain other risky actions on system tables. This is otherwise not
+allowed even for
Peter Eisentraut writes:
> On 2019-11-27 09:26, Michael Paquier wrote:
>> Peter, are you planning to look at that again? Note: the patch has no
>> reviewers registered.
> Here is an updated patch series.
> After re-reading the discussion again, I have kept the existing name of
> the option. I
On 2019-11-27 09:26, Michael Paquier wrote:
On Fri, Sep 13, 2019 at 06:39:40PM -0300, Alvaro Herrera wrote:
I think this patch is at a point where it merits closer review from
fellow committers, so I marked it RfC for now. I hope non-committers
would also look at it some more, though.
I guess
On Fri, Sep 13, 2019 at 06:39:40PM -0300, Alvaro Herrera wrote:
> I think this patch is at a point where it merits closer review from
> fellow committers, so I marked it RfC for now. I hope non-committers
> would also look at it some more, though.
I guess so. The patch has conflicts in the seria
On 2019-Jun-28, Peter Eisentraut wrote:
> Here is a new patch after the discussion.
>
> - Rename allow_system_table_mods to allow_system_table_ddl.
>
> (This makes room for a new allow_system_table_dml, but it's not
> implemented here.)
>
> - Make allow_system_table_ddl SUSET.
>
> - Add regres
On Sun, Jul 7, 2019 at 11:45:49PM -0400, Bruce Momjian wrote:
> On Mon, Jun 24, 2019 at 11:20:51AM -0400, Tom Lane wrote:
> > I do see value in two switches not one, but it's what I said above,
> > to not need to give people *more* chance-to-break-things than they
> > had before when doing manual
On Mon, Jun 24, 2019 at 11:20:51AM -0400, Tom Lane wrote:
> I do see value in two switches not one, but it's what I said above,
> to not need to give people *more* chance-to-break-things than they
> had before when doing manual catalog fixes. That is, we need a
> setting that corresponds more or l
Here is a new patch after the discussion.
- Rename allow_system_table_mods to allow_system_table_ddl.
(This makes room for a new allow_system_table_dml, but it's not
implemented here.)
- Make allow_system_table_ddl SUSET.
- Add regression test.
- Remove the behavior that allow_system_table_mod
On Mon, Jun 24, 2019 at 11:21 AM Tom Lane wrote:
> > I'm repeating myself, but I still think it's super-useful to
> > distinguish things which are "for expert use only" from things which
> > are "totally bonkers."
>
> Agreed, although "DML vs DDL" is a pretty poor approximation of that
> boundary.
Robert Haas writes:
> On Fri, Jun 21, 2019 at 4:37 PM Tom Lane wrote:
>> 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 unsafe
On Fri, Jun 21, 2019 at 4:37 PM Tom Lane wrote:
> 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 h
Hi,
On 2019-06-21 16:37:16 -0400, 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 re
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
Chapman Flack 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 wh
On 6/21/19 3:07 PM, Stephen Frost wrote:
> 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 do
Greetings,
* Tom Lane (t...@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 e
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Keep in mind that DML-on-system-catalogs is unfortunately a really
>> standard hack in extension upgrade scripts. (If memory serves,
>> some of our contrib scripts do that, and we've certainly told third
>> parties that it's the on
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2019-06-21 12:28:43 -0400, Tom Lane wrote:
> > Robert Haas writes:
> > > A related issue is that alter_system_table_mods prohibits both stuff
> > > that's probably not going to cause any big problem and stuff that is
> > > almost guarant
Hi,
On 2019-06-21 12:28:43 -0400, Tom Lane wrote:
> Robert Haas writes:
> > I kinda feel like we should prohibit DML on system catalogs, even by
> > superusers, unless you press the big red button that says "I am
> > definitely sure that I know what I'm doing."
>
> Keep in mind that DML-on-syste
On 2019-06-21 11:12:38 +0200, Peter Eisentraut wrote:
> After the earlier thread [0] that dealt with ALTER TABLE on system
> catalogs, I took a closer look at the allow_system_table_mods setting.
> I found a few oddities, and it seems there is some room for improvement.
I complained about this rec
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > I kinda feel like we should prohibit DML on system catalogs, even by
> > superusers, unless you press the big red button that says "I am
> > definitely sure that I know what I'm doing."
>
> Keep in mind that DML-on-syste
Robert Haas writes:
> I kinda feel like we should prohibit DML on system catalogs, even by
> superusers, unless you press the big red button that says "I am
> definitely sure that I know what I'm doing."
Keep in mind that DML-on-system-catalogs is unfortunately a really
standard hack in extension
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Jun 21, 2019 at 5:12 AM Peter Eisentraut
> wrote:
> > Any other thoughts?
>
> I kinda feel like we should prohibit DML on system catalogs, even by
> superusers, unless you press the big red button that says "I am
> definitely sure
On Fri, Jun 21, 2019 at 5:12 AM Peter Eisentraut
wrote:
> Attached are some patches to get the discussion rolling: One patch makes
> allow_system_table_mods settable at run time by superuser, the second
> one is a test suite that documents the current behavior that I gathered
> after analyzing the
After the earlier thread [0] that dealt with ALTER TABLE on system
catalogs, I took a closer look at the allow_system_table_mods setting.
I found a few oddities, and it seems there is some room for improvement.
Attached are some patches to get the discussion rolling: One patch makes
allow_system_t
25 matches
Mail list logo
