On Wed, 31 Jul 2002, Tom Lane wrote: > [EMAIL PROTECTED] (Neil Conway) writes: > > Mentioning that on -hackers would have been nice -- I've spent a while > > this week hacking autoconf / Makefiles to integrate libpqxx... > > Marc's opinion is not the same thing as a done deal ;-) --- we still > have to discuss this, and if someone's already doing the integration > work I think that's an important factor. > > > If we're going to start removing interfaces, I'd vote for the removal of > > perl5 & libpq++ as well as libpqxx. > > Agreed on that point. We shouldn't be promoting old, crufty interface > libraries when there are better ones available. > > I would personally prefer to see libpqxx integrated now, and then we > could plan to remove libpq++ in a release or two (after giving people > a reasonable opportunity to switch over). If anyone still cares about > libpq++ at that point, it could be given a home on gborg. > > One reason for wanting to integrate libpqxx is that I don't think we'll > find out anything about its portability until we get a lot of people > trying to build it. If it's a separate distro that won't happen quickly.
Who cares? Those that need a C++ interface will know where to find it, and will report bugs that they have ... why should it be tested on every platform when we *might* only have those on the Linux platform using it? What happens if/when libpqxx becomes the 'old, crufty interface' and something newer and shinier comes along? Where do we draw the line at what is in the distribution? For instance, why pgaccess vs a platform independent version of PgAdmin vs PHPPgAdmin? Hell, IMHO, PHPPgAdmin would most likely be more useful as more sites out there are running PHP then likely have TCL installed ... but someone that is using TCL/AolServer would definitely think otherwise ... By branching out the fat, we make it *easier* for someone to take on development of it ... would libpqxx ever have been developed if Joergen could have just worked on libpq++ in the first place, without having to submit patches? I really do not want to keep adding more users onto postgresql.org's servers just because "hey, their interface is cool and useful so let's add it into the main CVS repository and give them CVS access to save them having to submit patches" when we have a fully functioning collaborative development environment that gives them *more* then what we can give them now ... 1. the ability to pull in their own group of developers / committers on a per project basis 2. the ability to make releases *as required*, instead of having to wait for us to do the next release The benefit to us ... a much much smaller package of programs that have to be maintained and tested and debugged before a release ... Hell, how many packages do we currently have integrated with the whole distribution that rely *nothing* on the server other then to be able to use libpq to compile, that would benefit from being able to do releases? If, for instance, the libpq++ interface gets patched up to fix a race condition, or a vulnerability, the way things are right now, ppl have two choices: wait for v7.3 to be released sometime in October, or upgrade to the latest code via anon-cvs/cvsup ... and for package maintainers (rpm, deb, pkg), they pretty much have no choice but to wait ... Move libpq++ out as its own, independent project, and that patch would force a quick packaging and release of the new code, which those same package maintainers could jump on quickly and get out to *their* users ... How many packages/interfaces do we have 'integrated' right now that rely in no way on our release cycle *except* for the fact that they are integrated? The way we do things now made sense 7 years ago when we started out trying to get it as visible to the masses as possible ... and when we *didn't* have a clean/easy way to manage them externally ... it doesn't make any sense to do anymore, and hasn't for a fair time now ... ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
