Skip site navigation (1) Skip section navigation (2)

Re: search_path vs extensions

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Stark <stark(at)enterprisedb(dot)com>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Subject: Re: search_path vs extensions
Date: 2009-05-29 10:24:52
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thursday 28 May 2009 21:38:29 Tom Lane wrote:
> Greg Stark <stark(at)enterprisedb(dot)com> writes:
> > 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 ... naming conflicts between different extensions are going to be a
> problem for people no matter what.  Sticking them in different schemas
> doesn't really fix anything, it just means that you'll hit the problems
> later instead of sooner.

Yeah, to reiterate what I posted elsewhere, perhaps it'd be a good idea to 
give up on the search path idea altogether and think more in terms of an 
import facility like Python, Java, and sometimes Perl have.

In practice, I find a search path is just a tool to cause you to find the 
wrong stuff at the wrong time, and it continues to be a cause of confusion and 
security issues both in PostgreSQL and in Unix operating systems to this day.

In response to


pgsql-hackers by date

Next:From: Dimitri FontaineDate: 2009-05-29 10:38:49
Subject: Re: search_path vs extensions
Previous:From: Peter EisentrautDate: 2009-05-29 10:18:31
Subject: Re: search_path vs extensions

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group