Re: Trim the Fat (Was: Re: Open 7.3 items )

On Wed, 31 Jul 2002, Neil Conway wrote:

> On Wed, Jul 31, 2002 at 02:11:06AM -0300, Marc G. Fournier wrote:
> > On Wed, 31 Jul 2002, Tom Lane wrote:
> > > * libpqxx is not integrated into build process nor docs.  It should
> > > be integrated or reversed out before beta.
> >
> > I've requestsed that Jeorgen(sp?) move this over to GBorg ... its
> > something that can, and should be, built seperately from the base
> > distribution, along with at least a dozen other things we have bloating
> > the distribution now :(  but at least that one hasn't been integrated yet
> > ...
>
> Mentioning that on -hackers would have been nice -- I've spent a while
> this week hacking autoconf / Makefiles to integrate libpqxx...
>
> The problem I have with removing libpqxx is that libpq++ is a far
> inferior C++ interface. If we leave libpq++ as the only C++ interface
> distributed with PostgreSQL, there will be a tendancy for people
> using PostgreSQL & C++ to use the C++ support included with the
> distribution. Similarly, the Perl interface included with
> PostgreSQL is widely regarded as inferior to DBD::Pg.

Exactly what I mean ... we have *alot* of fat in the distribution ...
stuff that almost nobody uses ... or stuff that is generally inferior to
something else out there ...

What I *want* to see is a *base* server distribution vs the client side
code ... I *want* to be able to download libpq on a client machine to
install mod_php4, for example, without having to download everything else
that I'll never need ...

> If we're going to start removing interfaces, I'd vote for the removal of
> perl5 & libpq++ as well as libpqxx. We can add a section to the
> documentation listing the available language interfaces (for languages
> like Python, where several interfaces exist, this would probably be a
> good idea anyway).

Definitely ... python, tcl, pgaccess ... all of that needs to go ... they
are "specialty" stuff that, in some cases, have nothing to do with the
server itself ..

Anything that can build *from* libpq already being installed (except for
those that are required to admin the server (ie. psql, pg_dump, etc)
should be yanked and maintained outside of the distribution ... if nobody
is maintaining it, then obviously nobody is using it, so why carry it?

We have the environment now to keep the development 'centralized' through
GBorg, which also means that others can be provided with CVS access as
maintainers, if, for instance, Joergen(sp?) wishes to bring someone else
on board to help ...