On Thursday 28 May 2009 15:24:21 Stephen Frost wrote:
> I'm not real happy with it either. Sure, we can track module
> dependencies seperately, but if we go down this route then we have to
> come up with some concept of an extension namespace that different
> extension use and prefix their functions/tables/etc with to avoid
> overlap with each other. Gee, doesn't that sound familiar
I think what this comes down to is that you need nested schemas and a global
namespace rule. Then you can install things into
pg_extensions.postgis.submodule.special_type, etc. Makes sense on paper.
Note, however, that historically all the schemes that advocated the use of
something like /usr/local/$packagename/ for each package separately have
failed. And this is in spite of the fact that search path handling and
managing facilities for file systems are somewhat more powerful than
PostgreSQL's schema search path handling.
So unless we have any new insights in this problem that OS developers haven't
dealt with over the last few decades, I would feel more comfortable with an
all-in-one directory/schema approach, accompanied by a "package management"
system.
(One such new insight might be the Python/Java way of deeply nested package
naming systems where you have to manually pick out and import the pieces that
you want. But that might significantly change the whole schema search path
and name resolution system.)
