Nikolay Samokhvalov wrote: > 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).
That might be a good idea in any case. > 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). Build-time options will generally suffer from the problem that package builders will turn them all on and then users are stuck with all modules and then they're reallly not modular anymore. But I think your general idea of making them "more default" is sound. But it needs to be a run-time choice. Maybe we really just need to call them "modules" instead of "contrib", since users of Apache, PHP, or Linux will be familiar with that term. (I don't know how this overlaps with SQL modules though.) -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
