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

From: "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl>
To: "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Neil Conway <nconway(at)klamath(dot)dyndns(dot)org>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Trim the Fat (Was: Re: Open 7.3 items )
Date: 2002-08-02 17:53:48
Message-ID: 20020802175348.GC76690@xs4all.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Aug 01, 2002 at 09:07:46PM -0300, Marc G. Fournier wrote:
>
> > Of course my humble but thoroughly biased opinion is that libpq++ be
> > marked "legacy."
>
> No doubt, but, if we didn't "push" one interface over another, then it
> would be up to the end-users themselves to decide which one to install ...

In theory, yes. In this case, however, I see two arguments for making
the distinction anyway:

1. Some people won't want to go to the trouble of comparing available
interfaces, so they may default to libpq++ because it's what they found
first, or because they find mentions of it as the official C++ interface.
I think it would be a shame to have new users default to libpq++ "by
accident." I think many users would prefer to rely on the PostgreSQL
team's judgment--as they do by choosing Postgres in the first place.

2. I get the impression that libpq++ sort of got stuck before it was
completed. For the time being libpqxx appears to have better maintenance
prospects. Users will want to be aware of this before making a choice.

> Okay, then let's word it another way ... if libpq++ *wasn't* in the
> repository and part of the distribution, would you have a) started working
> on it sooner? b) would you have made it public earlier? c) would ppl
> have started to use it and stop'd using libpq++?

I'm not sure there's much point to going into a single example in detail,
but for completeness' sake I'll just answer these:

a) Yes.
b) No, because in my case I was encouraged by team members' endorsement of
first my suggestions for libpq++, and later a full replacement. Without
that, and without an active libpq++ maintainer around, libpqxx might never
have gotten off the ground.
c) I'd like to think so, yes--but exposure would have been harder.

> Basically, with libpq++ in the distribution, we are endorsing its use, so
> if we didn't put libpqxx into the repository, would ppl switch from the
> 'endorsed' to the 'unendorsed' version?
>
> By having libpq++ in the repository, we are adding weight to it that it
> wouldn't have if it were outside of the repository, making it more
> difficult for 'alternatives' to pop in ...

I definitely agree here. See above.

> > For the more general case, there's the problem of release management: who's
> > going to be taking care of synchronizing releases? This may require some
> > new infrastructure, such as a mailing list dedicated to the process, or one
> > restricted to subproject maintainers. Or something.

This reminds me of another potential complication: how would unbundling
affect the licensing situation? Mixing and matching components is good
in many ways, but it could complicate the situation for end-users--who
probably like to be able to rely on the team's judgment on this issue as
well.

I feel compelled at this point to admit that I prefer the GPL. This is
a personal preference, which I set aside because I wanted and expected
libpqxx to become the standard C++ interface. Had these interfaces not
been bundled, I would have had less incentive to conform to Postgres'
licensing conditions. I think having a different license would have
made everyone's life a little harder.

Jeroen

(and yes, I'm trying to repair my From: lines!)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Sullivan 2002-08-02 18:05:56 Re: FUNC_MAX_ARGS benchmarks
Previous Message Jeff Davis 2002-08-02 17:53:30 Re: Why is MySQL more chosen over PostgreSQL?