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!)
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? |