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


Sun, 11 Aug 2002 19:58:56 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
libpqxx
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

Sun, 11 Aug 2002 15:21:04 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: libpqxx 
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?



Mon, 12 Aug 2002 16:44:12 -0300 (ADT)
"Marc G. Fournier" <scrappy@hub.org>
Re: libpqxx 
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


Mon, 12 Aug 2002 21:59:37 +0200
"Jeroen T. Vermeulen" <jtv@xs4all.nl>
Re: libpqxx
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


Tue, 13 Aug 2002 19:18:32 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: libpqxx 
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

Tue, 13 Aug 2002 13:23:53 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: libpqxx 
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 ...


Tue, 13 Aug 2002 21:55:39 -0300 (ADT)
"Marc G. Fournier" <scrappy@hub.org>
Re: libpqxx 