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: Stephen Frost <sfrost(at)snowman(dot)net>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>
Subject: Re: search_path vs extensions
Date: 2009-05-29 10:18:31
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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" 

(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.)

In response to


pgsql-hackers by date

Next:From: Peter EisentrautDate: 2009-05-29 10:24:52
Subject: Re: search_path vs extensions
Previous:From: Peter EisentrautDate: 2009-05-29 10:08:15
Subject: Re: search_path vs extensions

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