Re: [pgsql-advocacy] [HACKERS] [OT] MySQL is bad, but THIS bad?
On Sat, May 20, 2006 at 02:29:01PM +0200, Dawid Kuroczko wrote: On 5/20/06, Lukas Smith [EMAIL PROTECTED] wrote: The improvements to the installer are great, but there simply needs to be a packaged solution that adds more of the things people are very likely to use. From my understanding Bizgres goes in that direction? I just think that whatever highly packaged solution PostgreSQL picks, this should be the download that is pushed at conferences, in articles and books. People with a clue will still know where they can get the clean base. Hmm, a Comprehensive PostgreSQL Archive Network? ;) I mean, something like CPAN, CTAN or CRAN? :) I mean, the -contrib is great, but pushing other things there is a bit tricky (to say the least) from the maintenance point of view. (Every bugfix, a new release of -contrib, etc, etc...). Then again PGfoundry is great to keep development centered, but finding and building a new package is not really a one-liner, and if you're unlucky you might get alpha-quality code installed. :) I don't see any reason why CPgAN would need to change pgFoundry at all. In fact, my thought was that any such system should use pgFoundry as it's backend/repository. I think a CPgAN-like solution would be the best. A uniform method of getting approved Pg extensions. It would simplify installing the extensions, and would encourage distributions to package such extensions. Somebody suggested apt-get install postgresql-contrib. Imagine: apt-get install postgresql-datatype-fqdn apt-get install postgresql-gist-ltree ...and so on. Except that apt doesn't work on all platforms. Though it would certainly make sense to look at lifting the framework for CPgAN from somewhere, rather than coding it ourselves. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgsql-advocacy] [HACKERS] [OT] MySQL is bad, but THIS bad?
On Sat, May 20, 2006 at 02:29:01PM +0200, Dawid Kuroczko wrote: On 5/20/06, Lukas Smith [EMAIL PROTECTED] wrote: The improvements to the installer are great, but there simply needs to be a packaged solution that adds more of the things people are very likely to use. From my understanding Bizgres goes in that direction? I just think that whatever highly packaged solution PostgreSQL picks, this should be the download that is pushed at conferences, in articles and books. People with a clue will still know where they can get the clean base. Hmm, a Comprehensive PostgreSQL Archive Network? ;) I mean, something like CPAN, CTAN or CRAN? :) I mean, the -contrib is great, but pushing other things there is a bit tricky (to say the least) from the maintenance point of view. (Every bugfix, a new release of -contrib, etc, etc...). Then again PGfoundry is great to keep development centered, but finding and building a new package is not really a one-liner, and if you're unlucky you might get alpha-quality code installed. :) I don't see any reason why CPgAN would need to change pgFoundry at all. In fact, my thought was that any such system should use pgFoundry as it's backend/repository. I think a CPgAN-like solution would be the best. A uniform method of getting approved Pg extensions. It would simplify installing the extensions, and would encourage distributions to package such extensions. Somebody suggested apt-get install postgresql-contrib. Imagine: apt-get install postgresql-datatype-fqdn apt-get install postgresql-gist-ltree ...and so on. Except that apt doesn't work on all platforms. Though it would certainly make sense to look at lifting the framework for CPgAN from somewhere, rather than coding it ourselves. A CPgAN would be a great idea in theory, but I have reservations. As a software developer, I'm fine with pgfoundery, but as a DB admin, and one who deploys data centers from time to time, I'd like to see something closer to the contrib. If I could have any influence at all, I'd like to see contrib essentially go away in the main distribution and replaced or renamed extensions. Then, some advisory group blesses extensions, and those extensions get packaged into a PostgreSQL extensions pack. I, again as a DB admin, would have NO problem with PostgreSQL playing favorites and picking best of breed for these extensions. ---(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: [pgsql-advocacy] [HACKERS] [OT] MySQL is bad, but THIS bad?
On 5/22/06, Mark Woodward [EMAIL PROTECTED] wrote: Except that apt doesn't work on all platforms. Though it would certainly make sense to look at lifting the framework for CPgAN from somewhere, rather than coding it ourselves. A CPgAN would be a great idea in theory, but I have reservations. As a software developer, I'm fine with pgfoundery, but as a DB admin, and one who deploys data centers from time to time, I'd like to see something closer to the contrib. If I could have any influence at all, I'd like to see contrib essentially go away in the main distribution and replaced or renamed extensions. Then, some advisory group blesses extensions, and those extensions get packaged into a PostgreSQL extensions pack. I, again as a DB admin, would have NO problem with PostgreSQL playing favorites and picking best of breed for these extensions. The problem with contrib is that no actively developed projects should be there. It is a feature, not a bug. If it is actively developed, it may be buggy. If it is proven over time, it can be safely used. Also, for a contrib it is inefficient to release a whole -contrib whenever a subproject releases new release. This forces -contrib to use stable-and-unchanging packages. This also makes it extremaly hard to put new or niche projects. New are risky, because they may need immediate bugfixes. Niche projects used by a minority of users bloat -contrib and force more frequent releases, both of which are well, not preferred. Of course -contrib is great, we all know it. I think a CPgAN would be a good testbed/incubator for new packages, some of which should eventually get into -contrib. Also, assuming there is a pginstall dbanme packagename interface, a -contrib package should register all its subpackages within that system. So, you install postgresql-contrib, and then you can type: pg_package install mydb index/ltree and later, provided you change your mind: pg_package remove mydb index/ltree (with -f option to insert CASCADE whenever possible ;)). This would be somewhat similar to current createlang(1) and friends. :) Regards, Dawid ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgsql-advocacy] [HACKERS] [OT] MySQL is bad, but THIS bad?
On Mon, May 22, 2006 at 08:56:14PM +0200, Dawid Kuroczko wrote: Also, assuming there is a pginstall dbanme packagename interface, a -contrib package should register all its subpackages within that system. So, you install postgresql-contrib, and then you can type: pg_package install mydb index/ltree Incidently, this reminds me of something I proposed late last year relating to easy installation of modules: http://archives.postgresql.org/pgsql-hackers/2005-09/msg00476.php To idea being that for most modules you only need a script to install it (declare functions and types). For these modules you can actually embed the script into the library itself. Thus, the installer only needs to be pointed to the shared object and it's done. If this installer tracked installed modules, you could use pg_depends to track what installed what and thus uninstall stuff afterwards. It might help pg_dump upgrades across versions. Anyway, it was just a thought and it didn't generate any comments at the time. Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
