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.
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