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.
David Fetter <[EMAIL PROTECTED]> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Remember to vote!
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?