On Fri, Apr 4, 2008 at 10:48 AM, Jeremy Drake <pgsql@jdrake.com> wrote:
> My opinion is, it doesn't matter what you call the modules/contrib stuff
> if I can't use it, and I can't use it if it is not loaded in my
> database, and I can't load it without superuser privileges.
Right. Which is why some of us have been suggesting a model where all
modules currently in contrib are installed by default, but not enabled
until a database owner actually issues some sort of "Install module
foo" or whatever it looks like. Database owner privs are probably as
low as we can reasonably set the bar... is that sufficiently low to be
useful? If not, I suppose that we could add a specific "install /
uninstall module" privilege that could be granted to non-db-owner
users if that's the way the ISP prefers to work.
Regarding PostGIS etc, my hope is that if we standardize the
installation of postgresql modules in this manner, it will be much
easier for sysadmins to e.g. yum install postgis - they don't have to
run any SQL scripts by hand, they can get packages built for their
platform and distributed using the preferred platform distribution
method, and the modules will only be enabled for those users that
specifically enable them in their databases. We can't force sysadmins
to install random third party extensions to postgresql, but we can
make it a lot easer than it currently is.
Alternately, if that's still not enough, then if we do standardise the
interface it would be easier to bundle third party modules that live
outside the main source tree - just stick em in /modules when building
the tar files and they'll end up installed and ready-to-enable when
built.
Hmm. We could even do that for existing contrib modules if we want
them to live outside the core project - for example because their
maintainers don't need commit access to core. It would be easy enough
to have the buildfarm fetch blessed modules from their real location
(pgfoundry?) so that we maintain good test coverage.
Cheers
Tom
