Re: erroneous restore into pg_catalog schema
Heikki Linnakangas <hlinnakangas@vmware.com>
From: Heikki Linnakangas <hlinnakangas@vmware.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, 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-13T17:32:24Z
Lists: pgsql-hackers
On 13.05.2013 19:59, Robert Haas wrote: > 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. Makes sense to me, actually. It's quite sensible to put functions, operators, etc. in pg_catalog. Especially if they're part of an extension. But I can't think of a good reason for putting a table in pg_catalog. Maybe some sort of control data for an extension, but seems like a kludge. Its contents wouldn't be included in pg_dump, for example. - Heikki
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