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" <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.
>
> 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 <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter
Remember to vote!