Proposal: allow installation of any contrib module simultaneously with Postgres itself

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