Re: erroneous restore into pg_catalog schema

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Heikki Linnakangas <hlinnakangas@vmware.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Erik Rijkers <er@xs4all.nl>, Dimitri Fontaine <dimitri@2ndquadrant.fr>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Kohei KaiGai <kaigai@kaigai.gr.jp>
Date: 2013-05-13T16:59:47Z
Lists: 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


Commits

  1. Extend and improve use of EXTRA_REGRESS_OPTS.

  2. Remove misplaced sanity check from heap_create().

  3. Silently ignore any nonexistent schemas that are listed in search_path.