On Tue, May 14, 2013 at 11:59 AM, Stephen Frost <sfr...@snowman.net> wrote: > * Dimitri Fontaine (dimi...@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. 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. 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. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers