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.) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers