On Sun, Jan 28, 2007 at 02:14:36PM -0800, Joshua D. Drake wrote: > > I don't think "all or nothing" is a good way to do this. 500 > > functions in a schema called extensions isn't much more helpful > > than 500 in public. There's a reason namespaces were invented > > long ago, and this is classic use case for same. :) > > I disagree, see my post previously about initializing the extensions > schema to not be accessible initially. It would be there, it would > be loaded, but it would take a superuser to grant ability to access > functions. > > This allows a clean distinction between the modules while allowing > their access on a case by case basis.
It's 982 functions as of this writing in CVS TIP's contrib. Do you not get how wacky it is to have that many functions, none of which have any collision-prevention built into their install scripts, in a flat namespace? Then again, you started the PL/PHP project, so maybe I shouldn't ask ;) > >>>>> --enable-extension=earthdistance > >>>> And have to parse for each extension? > >>> I don't see this as a big problem. > >> Well I am not really interesting in this. Someone else is welcome > >> to try that. > > > > It's really not hard, even for a C n00b like me. :) > > I didn't say it was hard. I said I wasn't interested :) I think it's necessary to get each in its own schema whether we have an initdb flag or not. 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 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
