Re: erroneous restore into pg_catalog schema

Stephen Frost <sfrost@snowman.net>

From: Stephen Frost <sfrost@snowman.net>
To: Marko Kreen <markokr@gmail.com>
Cc: Dimitri Fontaine <dimitri@2ndQuadrant.fr>, Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Erik Rijkers <er@xs4all.nl>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Kohei KaiGai <kaigai@kaigai.gr.jp>
Date: 2013-05-14T01:04:06Z
Lists: pgsql-hackers
* Marko Kreen (markokr@gmail.com) wrote:
> On Sat, May 04, 2013 at 10:57:44PM +0200, Dimitri Fontaine wrote:
> > Other than adminpack, I know of PGQ installing their objects in
> > pg_catalog. They only began doing that when switching to the CREATE
> > EXTENSION facility. And they set relocatable to false.
> 
> FYI - PgQ and related modules install no objects into pg_catalog.
> 
> I used schema='pg_catalog' because I had trouble getting schema='pgq'
> to work.  I wanted 'pgq' schema to live and die with extension,
> and that was only way I got it to work on 9.1.

I've read through this thread and I think you're the only person here
that I actually agree with..  I like the idea of having a schema that
lives & dies with an extension.  imv, putting random objects (of ANY
kind) into pg_catalog is a bad idea.  Sure, it's convenient because it's
always in your search_path, but that, imv, means we should have a way to
say "these schemas are always in the search_path", not that we should
encourage people to dump crap into pg_catalog.

	Thanks,

		Stephen

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.