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?
Show quoted text
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] libpqxxJDBC 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.
Import Notes
Resolved by subject fallback
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 ...