Re: Modifying and solidifying contrib
От | David Fetter |
---|---|
Тема | Re: Modifying and solidifying contrib |
Дата | |
Msg-id | 20070128220204.GD32296@fetter.org обсуждение исходный текст |
Ответ на | Re: Modifying and solidifying contrib ("Joshua D. Drake" <jd@commandprompt.com>) |
Ответы |
Re: Modifying and solidifying contrib
|
Список | pgsql-hackers |
On Sun, Jan 28, 2007 at 01:58:38PM -0800, Joshua D. Drake wrote: > > >> Well to me that gets a little messy. I mean: > >> > >> pg_catalog,public,<user schemas>,xml2,ltree (just to get a could > >> functions?) etc... > > > > Not as messy as trying to drop or re-create a package when there > > are already 500 functions in the public schema. > > I am not sure I understand the correlation. I am not suggesting we > install anything into public. They would all go into a single > additional schema called extensions or some such. I don't think "all or nothing" is a good way to do this. 500 functions in a schema called extensions isn't much more helpful than 500 in public. There's a reason namespaces were invented long ago, and this is classic use case for same. :) > >>>> Obviously the initdb switch could also be selective: > >>>> > >>>> initdb --enable-extensions > >>> If it were an initdb switch, I'd want to have something more > >>> like > >>> > >>> --enable-extension=earthdistance > >> And have to parse for each extension? > > > > I don't see this as a big problem. > > Well I am not really interesting in this. Someone else is welcome to > try that. It's really not hard, even for a C n00b like me. :) The only trick here, and again it's not a huge one, is to modify the postgresql.conf to have the correct default search_path. Cheers, D -- David Fetter <david@fetter.org> http://fetter.org/ phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter Remember to vote!
В списке pgsql-hackers по дате отправления: