Re: Trimming the Fat, Part Deux ... - Mailing list pgsql-hackers

On Thursday 01 August 2002 05:22 pm, Bruce Momjian wrote:
> Lamar Owen wrote:
> > It's already in CPAN.  A link to CPAN should suffice, IMHO.

> > I also thought we were discussing trimming the tree; and that was a good
> > feeling.

> Lamar, you said earlier today:
> > And the sooner our very old perl client goes away, the better I like it. 
> > It is a good client, don't get me wrong: but DBD:Pg is the standard now.

> So I assumed you wanted DBD:Pg.

I'm sorry I gave that impression; I was advocating removing the old Pg module 
in favor of people using the DBD::Pg module, which is distributed separately 
in CPAN.  I wasn't advocating bringing DBD::Pg into our distribution; my 
apologies for giving the wrong impression.  

DBD::Pg is typically distributed separately even in things such as Red Hat 
Linux, where it lives as a separate RPM.  There's also qt-PostgreSQL, 
php-pgsql, mod_auth_pgsql, and others that are doing quite OK outside our 
CVS.  The OpenACS/AOLserver PostgreSQL driver is a good example of a client 
outside our CVS that is being very well maintained by its group.

We should be providing the core client library, the backend, and 
documentation.  Contrib modules (earthdistance, etc), other clients, and 
things that don't fit in the core should be separately tarballed -- not 
necessarily separately CVS'd -- the AOLserver CVS, for instance, has a number 
of modules, all of which are somewhat independent.

Those modules then need to be buildable with a set of headers and makefile 
includes ONLY. Without assuming any paths.

>  DBD:Pg is a good example of an
> interface that hasn't advanced a quickly as it would have had it been in
> our CVS tree.  I have received a number of bug reports for it, and have
> them in my mailbox.  I have no idea if they made it into the CPAN
> version.  Moving interfaces out can be a problem too unless there is a
> large enough group to grow it.

Even if it's in a CVS at postgresql.org it doesn't necessarily need to be in 
the main tarball.  Even stuff in our CVS can languish -- witness the pgaccess 
revival outside the CVS tree.

The main tarball needs dramatic splitting into independent pieces, with a 
build framework that can deal with the pieces.  If I want a perl client, the 
backend, and PostGIS, I should be able to download the build system, the perl 
client, the backend, and PostGIS and make it work.  And each module shouldn't 
require the source of the other modules to build -- just the necessary bits 
in headers.  If I want just the python client, I should be able to download 
the client-side development headers, configure, and makefile, then download 
the python client, and build it.

And if I already have headers installed as part of a RPM or from source, I 
shouldn't need config.guess, configure, makefile.global, or anything but a 
set of C headers to get the python client to build.  IOW the python client 
should be somewhat independent.

It CAN be done -- the AOLServer/OpenACS PostgreSQL driver does it -- all it 
needs is the path to the headers and to libpq and it's off to the races.

I guess I'm saying that we're too big and too popular to include the kitchen 
sink in the tarball anymore.  We need to think more modularly -- and not 
assume a source tree with those modules.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11