Re: [HACKERS] Proposal: allow installation of any contrib module simultaneously with Postgres itself
"Nikolay Samokhvalov" <[EMAIL PROTECTED]> writes: > 1. Change default behaviour of .sql file so it will be > installed in schema instead of "public" (e.g., "hstore" > schema will contain all hstore relations and functions). This might be a good idea, but it's hardly transparent; it can be counted on to break the applications of just about everyone using those modules today. > 2. Allow running configure with "--with-" (or > "--enable-") 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 > "" 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. The problem with this proposal is that the ISPs aren't the ones running configure --- these days, most people are running prebuilt packages (RPMs or DEBs or what have you). So what you are hoping is that the packagers will choose to do this and thereby force these modules into the "standard" configuration for everybody using their packages. I'm not sure that the packagers will change ... well maybe Gentoo will, but not anyone with more conservative policies ... and I'm pretty sure any who do will get push-back from people who still won't trust contrib. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Proposal: allow installation of any contrib module simultaneously with Postgres itself
Nikolay Samokhvalov wrote: > 1. Change default behaviour of .sql file so it will be > installed in 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-" (or > "--enable-") 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 "" 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
[HACKERS] 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 .sql file so it will be installed in schema instead of "public" (e.g., "hstore" schema will contain all hstore relations and functions). 2. Allow running configure with "--with-" (or "--enable-") 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 "" 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
