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