Re: search_path vs extensions

On Thu, May 28, 2009 at 2:27 PM, Greg Stark <stark(at)enterprisedb(dot)com> wrote:
> On Thu, May 28, 2009 at 5:30 PM, David E. Wheeler <david(at)kineticode(dot)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