Re: erroneous restore into pg_catalog schema
От | Dimitri Fontaine |
---|---|
Тема | Re: erroneous restore into pg_catalog schema |
Дата | |
Msg-id | m2k3m2ay1s.fsf@2ndQuadrant.fr обсуждение исходный текст |
Ответ на | Re: erroneous restore into pg_catalog schema (Greg Stark <stark@mit.edu>) |
Список | pgsql-hackers |
Greg Stark <stark@mit.edu> writes: > On Tue, May 14, 2013 at 11:59 AM, Stephen Frost <sfrost@snowman.net> wrote: >> 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. +1 Your description of how bad this idea is is the best I've read I think: > 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. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
В списке pgsql-hackers по дате отправления: