Re: erroneous restore into pg_catalog schema

Dimitri Fontaine <dimitri@2ndquadrant.fr>

From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
To: Stephen Frost <sfrost@snowman.net>
Cc: Greg Stark <stark@mit.edu>, Marko Kreen <markokr@gmail.com>, 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-06-10T14:45:10Z
Lists: pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> Having a schema that isn't pg_catalog doesn't necessairly mean we need a
> schema per extension.  Just a 'pg_extensions' schema, which is added to
> search_path behind the scenes (just like pg_catalog..) would be better
> than having everything go into pg_catalog.  I'd prefer that we let the
> admins control both where extensions get installed to and what schemas
> are added to the end of the search_path.

That was discussed in the scope of the first extension patch and it took
us about 1 year to conclude not to try to solve search_path at the same
time as extensions. I'm not convinced we've had extensions for long
enough to be able to reach a conclusion already, but I'll friendly watch
that conversation happen again.

My opinion is that a pg_extension schema with a proper and well
documented set of search_path properties would be good to have. A way to
rename it per-database doesn't strike me as that useful as long as we
have ALTER EXTENSION … SET SCHEMA …

The current default schema where to install extensions being "public",
almost anything we do on that front will be an improvement.

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support


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.