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

From Robert Haas
Subject Re: erroneous restore into pg_catalog schema
Date
Msg-id CA+TgmoZqeddRsEKWe7EZ+4=16SqFgUiPanQLfHKxiJF=Ovye0Q@mail.gmail.com
Whole thread Raw
In response to Re: erroneous restore into pg_catalog schema  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: erroneous restore into pg_catalog schema  (Andres Freund <andres@2ndquadrant.com>)
Re: erroneous restore into pg_catalog schema  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: erroneous restore into pg_catalog schema  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
On Mon, May 13, 2013 at 12:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
>> Another way to fix that inconsistency is to consider that
>> allow_system_table_mods should gate table creations not just drops in
>> pg_catalog.  I'm not real sure why this wasn't the case all along ...
>
> 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.  It's perfectly obvious that people
want to be able to create objects in pg_catalog; shall we adopt a rule
that you can put extension there, as long as those extensions don't
happen to contain tables?  That is certainly confusing and arbitrary.

I suppose we could add a GUC, separate from allow_system_table_mods,
to allow specifically adding and dropping objects in pg_catalog.  It
would be consistent, and there would sure be a place to document it.
And it would make it easy to emit the right error-hint.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Jerry Sievers
Date:
Subject: Re: Re: [GENERAL] pg_upgrade fails, "mismatch of relation OID" - 9.1.9 to 9.2.4
Next
From: Fabien COELHO
Date:
Subject: Re: Add more regression tests for dbcommands