Re: search_path vs extensions

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: search_path vs extensions
Дата
Msg-id 200905291318.31518.peter_e@gmx.net
обсуждение исходный текст
Ответ на Re: search_path vs extensions  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: search_path vs extensions  (Dimitri Fontaine <dfontaine@hi-media.com>)
Список 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" 
system.

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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: search_path vs extensions
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: search_path vs extensions