* Jeremy Drake <[EMAIL PROTECTED]> [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, [EMAIL PROTECTED] command like a king, http://www.highrise.ca/ work like a slave.
signature.asc
Description: Digital signature