Обсуждение: libpqxx
We still haven't really decided what to do about libpqxx. The only argument I've heard so far against distributing it separately is that it would induce users to use libpq++ instead. I think having both libraries in the distribution is going to be even more confusing, especially since one is "old and well-tested" and one is brand new. The problem I see now is that libpqxx has a completely different build system and documentation system. This is also not going to help users find and use it and it's also going to be a maintenance headache. I don't necessarily want libpqxx to change it, but I feel it would be better off maintained separately. I wouldn't mind if we package libpq++ separately as well and tell users that we have these two libraries and they can pick one. And before someone suggests an --enable-libpqxx option: That's not the solution to these problems, it's only a way to hide them. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> The problem I see now is that libpqxx has a completely different build
> system and documentation system.
Unless someone's going to do the work to integrate libpqxx into our
build/documentation system, I have to agree with Peter: it should not
be part of our core distribution.
Since Marc's been moaning about bloat, I'm sure he'll vote for pulling
both libpq++ and libpqxx from the core distro and making them separate
packages. This would be okay with me.
However: making libpq++ buildable standalone would take some work too.
Any way you slice it, we need some work here... any volunteers?
regards, tom lane
On Sun, 11 Aug 2002, Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > The problem I see now is that libpqxx has a completely different build > > system and documentation system. > > Unless someone's going to do the work to integrate libpqxx into our > build/documentation system, I have to agree with Peter: it should not > be part of our core distribution. For this, all I've been waiting for is for J to get the standalone to build and then going to dive into that ... > Since Marc's been moaning about bloat, I'm sure he'll vote for pulling > both libpq++ and libpqxx from the core distro and making them separate > packages. This would be okay with me. Okay, but if we are going to pull libpqxx, what about the other lib's too? > However: making libpq++ buildable standalone would take some work too. > Any way you slice it, we need some work here... any volunteers?
On Mon, Aug 12, 2002 at 04:44:12PM -0300, Marc G. Fournier wrote: > For this, all I've been waiting for is for J to get the standalone to > build and then going to dive into that ... I added Ray's changes a few days back, which may help. My handicap is that I appear to be on a newer version of libtoolize than you are, which is where Marc's build appears to fail, so obviously it just builds on my system like it did all along. So, any luck with the version currently in CVS? Jeroen
Marc G. Fournier writes: > Okay, but if we are going to pull libpqxx, what about the other lib's too? Certain things apply to libpqxx that don't all apply to the others libs: It is maintained and developed independently anyway. It's new and not integrated yet. It's a different programming language. It's a non-standard interface. It's big. If there is ever going to be any motion toward separating parts of the source tree, libpqxx has to be the start. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> Marc G. Fournier writes:
>> Okay, but if we are going to pull libpqxx, what about the other lib's too?
> Certain things apply to libpqxx that don't all apply to the others libs:
> It is maintained and developed independently anyway. It's new and not
> integrated yet. It's a different programming language. It's a
> non-standard interface. It's big.
> If there is ever going to be any motion toward separating parts of the
> source tree, libpqxx has to be the start.
I agree with Peter's points here --- but separating libpqxx alone isn't
the right answer. We need to pull both libpqxx and libpq++ at the same
time, else we'll be creating the wrong impression about what we think of
libpqxx.
Another thing that would be reasonable to separate out in the near term
is interfaces/perl5, which is not favored over the DBI driver.
JDBC and ODBC are almost separate projects already, and perhaps should
be cut loose so they can have their own release cycles. I'd defer to
the maintainers of those interfaces about what they want to do, though.
I'm not particularly concerned about removing the other interfaces such
as libpgtcl and python. They're not large and they're (AFAIK) the only
alternatives for their languages.
regards, tom lane
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: 13 August 2002 18:24 > To: Peter Eisentraut > Cc: Marc G. Fournier; PostgreSQL Development > Subject: Re: [HACKERS] libpqxx > > > JDBC and ODBC are almost separate projects already, and > perhaps should be cut loose so they can have their own > release cycles. I'd defer to the maintainers of those > interfaces about what they want to do, though. I've been thinking for some time that ODBC should be split. We have been doing our own releases of the Win32 binaries and packages for some time - I don't remember them ever coinciding with PostgreSQL release. I'm not even sure what state the code has been in in recent PostgreSQL releases, I guess it's quite possible that people that have compiled from the tarball are using code that is from between the independent releases. Hiroshi might know more about this. Regards, Dave.
On Tue, 13 Aug 2002, Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > Marc G. Fournier writes: > >> Okay, but if we are going to pull libpqxx, what about the other lib's too? > > > Certain things apply to libpqxx that don't all apply to the others libs: > > It is maintained and developed independently anyway. It's new and not > > integrated yet. It's a different programming language. It's a > > non-standard interface. It's big. > > > If there is ever going to be any motion toward separating parts of the > > source tree, libpqxx has to be the start. > > I agree with Peter's points here --- but separating libpqxx alone isn't > the right answer. We need to pull both libpqxx and libpq++ at the same > time, else we'll be creating the wrong impression about what we think of > libpqxx. > > Another thing that would be reasonable to separate out in the near term > is interfaces/perl5, which is not favored over the DBI driver. > > JDBC and ODBC are almost separate projects already, and perhaps should > be cut loose so they can have their own release cycles. I'd defer to > the maintainers of those interfaces about what they want to do, though. > > I'm not particularly concerned about removing the other interfaces such > as libpgtcl and python. They're not large and they're (AFAIK) the only > alternatives for their languages. god, ppl finally catch up *roll eyes* as for libpgtcl and python ... python is seperately maintained by D'Arcy Cain, so that one isn't a problem ... but who is maintaining libpgtcl? libpq++ was "the only alternatives for their language" until libpqxx came along, and from talking to J, libpqxx started off as an attempt to "fix the bugs" in libpq++ that turned out to be so numerous that starting from scratch was easier ... Basically, if somethign doesn't have a maintainer, we're promoting something we shouldn't be in the first place ...