Re: erroneous restore into pg_catalog schema
Andres Freund <andres@2ndquadrant.com>
From: Andres Freund <andres@2ndquadrant.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
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-13T17:18:28Z
Lists: pgsql-hackers
On 2013-05-13 13:04:52 -0400, Robert Haas wrote: > On Mon, May 13, 2013 at 1:03 PM, Andres Freund <andres@2ndquadrant.com> wrote: > >> 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. > > > > Why don't we just prohibit deletion/modification for anything below > > FirstNormalObjectId instead of using the schema as a restriction? Then > > we can allow creation for tables as well. > > We currently do, but that led to problems with $SUBJECT. But we currently don't allow to drop. Which is confusingly inconsistent. And allowing object creation withing pg_catalog only from within extension scripts and not from normal SQL sounds like a *very* poor workaround giving problems to quite some people upgrading from earlier releases. Especially from those where we didn't have extensions. And I don't see why allowing consistent relation creation/removal from pg_catalog is conflicting with fixing the issue at hand? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
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