Joshua D. Drake wrote: > > > > This seems like a good first step in growing a packaging > > infrastructure. I'd rather grow it organically than try to design it > > all up front. > > > > I am in Denver and have spotty inet access so forgive me. So where does > this above leave us? What are we doing?
I was kind of unclear on that too. It seems we are trying to address several issues: visibility of contrib, installation of contrib, etc. We discussed whether we put the functions in public, a schema for all contrib, or a schema for each contrib module, and then there was the discussion of how to configure someone using ten /contrib modules, or at least wanting them all to be accessible. And then there was the idea of allowing schema permissions to control access, so perhaps we could install more of /contrib by default, and allow the administrator to just enable/disable them via permissions. Personally, I think that might be the best approach because it allows us to eliminate the install process, but doesn't make the database less secure --- the administrator enables/disables them at runtime, or at least could. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
