* Jeremy Drake <pgsql@jdrake.com> [080404 01:27]:
> 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.
Would it be possible to "change" the rules a bit to make this "more
friendly"?
Right now, the "superuser needed" part of installing a module (like
earthdistance or cube) is the "LANGUAGE C" functions, and that's the
part that allows the "user" to load random code that can gets run as the
postgres user. All the other function/domain stuff doesn't need
superuser privileges.
What if you didn't need super-user privileges to load "C" functions, on
the conditions that:
1) There is no / in the obj_file filename (or some other "sanitizing" rules)
2) You're database owner
This follows the precedence of the CREATE LANGUAGE, which allows
database owners to install a language as long as it's "known" on the
system.
Doing this still wouldn't help the poor user who's ISP refuses to do
anything besides ./configure && make && make install of base PostgreSQL,
but it does allow distros/packages to make more packages available that
don't need to be "on" in every database, but where database owners can
easily enable any of the installed packages without further ISP admin
intervention.
This changes the game slightly from trying to get systems to come with
PostreSQL "modules" installed into PostgreSQL by default, to where
systems come with PostgreSQL "module" *packages* (rpms, debs, pkg, etc)
installed by default, and the DB owners can do the "PostgreSQL install"
part themselves.
Would this slight change of the game be of any value?
a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
