On Sun, Jan 28, 2007 at 10:10:14AM -0800, Joshua D. Drake wrote:
> David Fetter wrote:
> > On Sat, Jan 27, 2007 at 09:49:25PM -0800, Joshua D. Drake wrote:
> >> Tom Lane wrote:
> >>> "Joshua D. Drake" <[EMAIL PROTECTED]> 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.
> 
> 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.

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

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

Remember to vote!

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faq

Reply via email to