Thread: Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
On 5/20/06, Lukas Smith <smith@pooteeweet.org> 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 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.
Regards,
Dawid
> > 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. :) > Mammoth PostgreSQL was designed to fill this role. It is an FOSS project (www.mammothpostgresql.org) that is designed to be a COMPLETE postgresql distribution. Joshua D. Drake >
On Sat, May 20, 2006 at 02:29:01PM +0200, Dawid Kuroczko wrote: > On 5/20/06, Lukas Smith <smith@pooteeweet.org> 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 jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
On 5/22/06, Mark Woodward <pgsql@mohawksoft.com> 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
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.
> On Sat, May 20, 2006 at 02:29:01PM +0200, Dawid Kuroczko wrote: >> On 5/20/06, Lukas Smith <smith@pooteeweet.org> 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.