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."
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
