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
-
Extend and improve use of EXTRA_REGRESS_OPTS.
- 4ae5ee6c9b4d 9.3.0 cited
-
Remove misplaced sanity check from heap_create().
- a475c6036752 9.3.0 cited
-
Silently ignore any nonexistent schemas that are listed in search_path.
- 880bfc3287dd 9.2.0 cited