Re: erroneous restore into pg_catalog schema - Mailing list pgsql-hackers

From Tom Lane
Subject Re: erroneous restore into pg_catalog schema
Date
Msg-id 7080.1368466054@sss.pgh.pa.us
Whole thread Raw
In response to Re: erroneous restore into pg_catalog schema  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, May 13, 2013 at 12:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Uh, scratch that last comment: actually, allow_system_table_mods *did*
>> gate that, in every existing release.  I bitched upthread about the fact
>> that this was changed in 9.3, and did not hear any very satisfactory
>> defense of the change.

> It disallowed it only for tables, and not for any other object type.
> I found that completely arbitrary.

No doubt, but nonetheless the name of the GUC is allow_system_TABLE_mods,
not allow_system_object_mods.  And removing just one part of its
longstanding functionality, in a way that creates the type of pg_dump
hazard this thread started with, is as arbitrary as things get.

We don't have time anymore to redesign this for 9.3, so I think just
putting back that one error check might be a reasonable fix for now.

> I suppose we could add a GUC, separate from allow_system_table_mods,
> to allow specifically adding and dropping objects in pg_catalog.

+1 ... for 9.4.  Or maybe the right thing is to replace all these tests
with checks on whether the objects are pinned (which, again, already
happens for the DROP case).  It's not immediately clear to me why we
need any of these restrictions for non-pinned objects.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: erroneous restore into pg_catalog schema
Next
From: Heikki Linnakangas
Date:
Subject: Re: erroneous restore into pg_catalog schema