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

Re: search_path vs extensions

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org, Stephen Frost <sfrost(at)snowman(dot)net>, 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:38:49
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

Le 29 mai 09 à 12:18, Peter Eisentraut a écrit :
> 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.
> (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.)

We'd still need search_path in there, as Python's still using a path.  
With 'default' search_path you'd have to qualify your type as  
pg_extensions.postgis.submodule.special_type, with pg_extensions in  
search_path the following notation would find it too:  
And if you have pg_extensions.postgis.submodule in the search_path,  
then you can use special_type without having to (nest-) schema qualify  

I like this idea, which sounds compatible with what we already have  
now (meaning current semantics of search_path still apply).


PS: we still have to provide users with easy tools to (dynamically)  
manage search_path, don't we?
(I prefer not to start the search_path management tool ideas right  

PPS: doesn't look like it's failing. (yet?)

"In GoboLinux you don't need a package database because the filesystem  
is the database: each program resides in its own directory, such as / 
Programs/Xorg-Lib/7.4 and /Programs/KDE-Libs/4.2.0."

In response to


pgsql-hackers by date

Next:From: Peter EisentrautDate: 2009-05-29 10:41:12
Subject: Re: PostgreSQL Developer meeting minutes up
Previous:From: Peter EisentrautDate: 2009-05-29 10:24:52
Subject: Re: search_path vs extensions

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