On Thu, May 28, 2009 at 2:27 PM, Greg Stark <st...@enterprisedb.com> wrote: > On Thu, May 28, 2009 at 5:30 PM, David E. Wheeler <da...@kineticode.com> > wrote: >> Yes, just as long as your extensions schema doesn't turn into a bricolage of >> stuff. I mean, if I use a lot of extensions, it means that I end up with a >> giant collection of functions and types and whatnot in this one namespace. >> PHP programmers might be happy with it, but not I. ;-P > > I don't understand what storing them in different namespaces and then > putting them all in your search_path accomplishes. You end up with the > same mishmash of things in your namespace.
+1! That's the thing that's really mystifying me about this whole conversation. It seems this compounds the work of managing extension by requiring every extension to require an extra post-installation step where we update everyone's search path (and that step can't be automated because there's no way for the extension installation process to update all of the places search_paths might be stored, even if it could tell which ones ought to be updated). Having a global search_path_suffix will help with this a little bit, but I think there are corner cases (such as the ones I mentioned upthread) where that's not really going to be enough either. It feels like a Java CLASSPATH, or installing every application into /usr/local/<application-name> so that your path has 50 bin directories in it. It also seems to me that we're getting seriously sidetracked from the dependency-tracking part of this project which seems to me to be a much deeper and more fundamental issue. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers