Re: erroneous restore into pg_catalog schema - Mailing list pgsql-hackers

Greg,

* Greg Stark (stark@mit.edu) wrote:
> On Tue, May 14, 2013 at 11:59 AM, Stephen Frost <sfrost@snowman.net> wrote:
> > * Dimitri Fontaine (dimitri@2ndQuadrant.fr) wrote:
> >> I'm not sure I agree with that view about pg_catalog. Sometimes we talk
> >> about moving some parts of core in pre-installed extensions instead, and
> >> if we do that we will want those extensions to install themselves into
> >> pg_catalog.
> >
> > For my part, I'd still prefer to have those go into a different schema
> > than into pg_catalog.  Perhaps that's overkill but I really do like the
> > seperation of system tables from extensions which can be added and
> > removed..
>
> This was discussed previously. It's a bad idea. It's very tempting but
> it doesn't scale. Then every user needs to know every schema for every
> extension they might want to use.

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.

> It's exactly equivalent to the very common pattern of sysadmins
> installing things into /usr/local/apache, /usr/local/kde,
> /usr/local/gnome, /usr/local/pgsql, etc. Then every user needs a
> mile-long PATH, LD_LIBRARY_PATH, JAVACLASSPATH, etc. And every user
> has a slightly different ordering and slightly different subset of
> directories in their paths resulting in different behaviours and
> errors for each user.

This would be because admins can't maintain control over the PATH
variable in every shell, not even to simply add things to it, and so
users end up building up their own PATH by hand over time.  What's more,
even with a distro like Debian, you don't keep all of your system
configuration (eg: /etc) in the same place that all the user-called
binaries (/usr/bin) go, nor do you put the libraries (eg: functions in
extensions which are not intended to be user-facing) in the same place
as binaries.

> A correctly integrated package will use standard
> locations and then users can simply refer to the standard locations
> and find what's been installed. It would be ok to have a schema for
> all extensions separately from the core, but it can't be a schema for
> each extension or else we might as well not have the extension
> mechanism at all. Users would still need to "install" the extension by
> editing their config to refer to it.

... because we don't give the admins (or even the extensions
themselves..) any ability to handle this.
Thanks,
    Stephen