Re: Modifying and solidifying contrib - Mailing list pgsql-hackers

From David Fetter
Subject Re: Modifying and solidifying contrib
Date
Msg-id 20070128071917.GG26901@fetter.org
Whole thread Raw
In response to Re: Modifying and solidifying contrib  ("Joshua D. Drake" <jd@commandprompt.com>)
Responses Re: Modifying and solidifying contrib
List pgsql-hackers
On Sat, Jan 27, 2007 at 09:49:25PM -0800, Joshua D. Drake wrote:
> Tom Lane wrote:
> > "Joshua D. Drake" <jd@commandprompt.com> writes:
> >> So what are we thinking here? Along with my suggestion of
> >> extensions / contrib that we modify initdb to load an extensions
> >> schema with all extensions into template1?
> > 
> > No, I don't think so.  If you do that it's effectively moving all
> > that stuff into core, especially if you haven't provided a way to
> > turn it off.
> 
> O.k. any thoughts there? What if we didn't make the extensions
> schema PUBLIC? Meaning that explicits rights would have to be given
> for the extensions to be used by anyone but a super user?

Whether they're auto-installable or not, I'd vote for putting each one
in its own schema by default.  That way, people can get an excellent
idea just by looking at what schemas exist what extensions are
installed in a given DB, and it's fairly straight-forward to remove
the thing simply by dropping the schema cascade.

> 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

Cheers,
D
-- 
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778        AIM: dfetter666                             Skype: davidfetter

Remember to vote!


pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Modifying and solidifying contrib
Next
From: "Kevin Barnard"
Date:
Subject: Re: Modifying and solidifying contrib