Re: Trim the Fat (Was: Re: Open 7.3 items ) - Mailing list pgsql-hackers

On Wed, 31 Jul 2002, Andrew Sullivan wrote:

> On Wed, Jul 31, 2002 at 02:08:33PM -0300, Marc G. Fournier wrote:
> > On Wed, 31 Jul 2002, Tom Lane wrote:
>
> > > One reason for wanting to integrate libpqxx is that I don't think we'll
> > > find out anything about its portability until we get a lot of people
> > > trying to build it.  If it's a separate distro that won't happen quickly.
> >
> > Who cares?  Those that need a C++ interface will know where to find it,
> > and will report bugs that they have ... why should it be tested on every
> > platform when we *might* only have those on the Linux platform using it?
>
> This seems a bad argument.  You can't say "we support interface xyz"
> and never test it on anything except i80x86 Linux.  Somebady comes
> along and tries to make it go on Solaris, and it doesn't work: poof,
> the cross-platform reputation that you and other have worked hard to
> burnish goes away.  Never mind that it's only a client library.

This is my point, actually ... there are *two* things we should be
guarantee'ng to work cross-platform: the server and libpq ... (note that
with 'the server', I'm including the administrative commands and scripts,
like psql and initdb) ...

Take a look at libpq++ as a perfect example ... we've been distributing
that forever, but Tom himself states its 'old and crufty' ... but its also
the "officially supported version", so its what ppl generally use ...

We should be focusing on "the server", not the "clients" ...

Another point ... we have a load of stuff in contrib ... originally,
contrib was meant basically as a temporary storage while we decide if we
put it into the mainstream, and its grown into "if we have nowhere else to
put it, shove it in here and forget it" ... how many ppl know if all of
those that are in there even *work*?  We know they compile, but do they
actually work?

> Besides, more generally, Postgres already has a reputation as being
> difficult to install.  The proposal to separate out all the "non-basics"
> (I'm not even sure how one would draw that line: maybe a server-only
> package and a client-library package run through GBorg?) would mean that
> anyone wanting to do something moderately complicated would have a yet
> higher hurdle.  Isn't that a problem?

Like what?  I work at a local University and am slowly getting PgSQL used
for more and more things ... I have one server that is the database
server, but everything else connects to that ...

As it is now, I have to download the whole distribution, configure the
whole distribution, compile it and then install .. which, of course,
installs a bunch of stuff that I just don't need (initdb, psql, libpq++,
etc, etc) ... all I need is libpq.a ...

How many thousands of web sites out there don't offer PgSQL due to teh
hassle?  Everyone is arguing 'why mysql vs pgsql?' ... if we had a simple
'libpq.tar.gz' that could be downloaded, nice and small, then we've just
made enabling PgSQL by default in mod_php4 brain dead ...