Discussion "tsearch in core patch, for inclusion" shows (http://archives.postgresql.org/pgsql-hackers/2007-01/msg01165.php and following http://archives.postgresql.org/pgsql-hackers/2007-01/msg01186.php) that there are some problems with contrib promotion and expansion. I've encountered with bad awareness and some kind of fears (due to "possible security holes" and similar reasons) regarding contrib modules. For example, hstore is very good thing that helps to resolve many issues (e.g. logging tasks), but not many people know are aware of it, and there are very few hosting providers which include hstore to Postgres installation.
So, it would be really good if documentation and the main website itself include more information describing the modules (maybe to review README files and include them all in the docs?). But I want to propose something more. It's clear that some ISPs are afraid of contrib modules installation, many of which are very useful and have reliable code. But, those ISPs are not afraid to install, say, PHP with a dozen modules (extensions). Why? Besides the fact that PHP modules are very good described in the main PHP manual, I see very simple reason: to install a contrib module you must go to contrib dir and run _another_ "make install" (wth following "psql .. < module.sql" surely), while to install PHP extension you should only add "--with-modulename" to the configuration command. Well, my proposal is simple: 1. Change default behaviour of <MODULE_NAME>.sql file so it will be installed in <MODULE_NAME> schema instead of "public" (e.g., "hstore" schema will contain all hstore relations and functions). 2. Allow running configure with "--with-<MODULE_NAME>" (or "--enable-<MODULE_NAME>") to include compilation of module's libraries simultaneously with Postgres itself and including running of module's registration SQLs (from that .sql files) simultaneously with cluster creation (in other words, with inidb invocation -- this will add "<MODULE_NAME>" schema to template0). This will simplify the procedure of starting to use contrib modules and will help to promote the modules themselves (and, as a result, some PostgreSQL's advanced features). I think many projects have similar behaviour with regard to their extensions. And ISPs will install PostgreSQL with a bundle of useful and "trusted" extensions, simply running "./configure --with-tsearch2 --with-hstore --with-dblink" (actually, I hope that tsearch2 will be in core, but this is really good example at the moment ;-) ) - like they do with PHP, Apache and other software. Let's make the usage of contrib modules more user-friendly. -- Best regards, Nikolay ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq