Re: search_path vs extensions

Hi,

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:
postgis.submodule.special_type.
And if you have pg_extensions.postgis.submodule in the search_path,
then you can use special_type without having to (nest-) schema qualify
it.

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

Regards,
--
dim

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

PPS: http://www.gobolinux.org/ 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."