The Hermit Hacker wrote:
> 
> On Mon, 15 May 2000, Peter Eisentraut wrote:
> 
> > On Mon, 15 May 2000, The Hermit Hacker wrote:
> >
> > > Hrmmm, some sort of --with-berkeley-db configure switch, so by default, it
> > > uses ours, but if someone wants to do the db code, it could plug-n-play?
> >
> > But wasn't the main reason Michael Olson gave that a lot of code could be
> > removed because Berkeley DB does it for you? But with that switch we'd end
> > up with more code, not less.
> 
> right, and my point was that, up until now, we've worked at making sure
> that the whole thing is self-contained ... as soon as we throw in a
> third-party piece of software that is *efffectively* our guts, we now
> throw in a new point of failure for the end users ... what happens if, a
> year down the road, SleepyCat decides that v4.0 falls undera  new license
> that negates our ability to use it?  we've just drop'd all our guts in
> favor of theirs and now what?

There could be some ways to get a twisted license (like Medusa used in
Zope)
where the Berkeley DB used in PostgreSQL is free but used without
postgres 
is still under the original Sleepycat terms.

That arrangement seems to work quite nicely with Zope.

I still don't see how we could replace some part of storage manager and 
access methods guts with Berkeley DB and still keep the extended
features
like R-trees and MVCC (and sure there are others), and integrate two
types 
of transaction management on top of them.

> I'm not saying that using some of SleepyCat's stuff for backend is a bad
> idea, but I'm saying that we shouldn't be relying on it ... add on, yes ...

But what would the idea of such add-on be ? 

Does it offer real advantages over our current scheme ?
If so, is the integrating effort significantly less than fixing what we
have ?

BTW, is there a general-purpose optimisation library available that we 
could use instead of our current one ? ;)

-----------------
Hannu

Mon, 15 May 2000 20:03:30 +0300
Hannu Krosing <hannu@tm.ee>
Re: Proposal: replace no-overwrite with Berkeley DB
On Mon, 15 May 2000, Peter Eisentraut wrote:

> On Mon, 15 May 2000, The Hermit Hacker wrote:
> 
> > Hrmmm, some sort of --with-berkeley-db configure switch, so by default, it
> > uses ours, but if someone wants to do the db code, it could plug-n-play?
> 
> But wasn't the main reason Michael Olson gave that a lot of code could be
> removed because Berkeley DB does it for you? But with that switch we'd end
> up with more code, not less.

right, and my point was that, up until now, we've worked at making sure
that the whole thing is self-contained ... as soon as we throw in a
third-party piece of software that is *efffectively* our guts, we now
throw in a new point of failure for the end users ... what happens if, a
year down the road, SleepyCat decides that v4.0 falls undera  new license
that negates our ability to use it?  we've just drop'd all our guts in
favor of theirs and now what?

I'm not saying that using some of SleepyCat's stuff for backend is a bad
idea, but I'm saying that we shouldn't be relying on it ... add on, yes
... exclusive, no ...


Mon, 15 May 2000 14:36:27 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: Proposal: replace no-overwrite with Berkeley DB
> right, and my point was that, up until now, we've worked at making sure
> that the whole thing is self-contained ... as soon as we throw in a
> third-party piece of software that is *efffectively* our guts, we now
> throw in a new point of failure for the end users ... what happens if, a
> year down the road, SleepyCat decides that v4.0 falls undera  new license
> that negates our ability to use it?  we've just drop'd all our guts in
> favor of theirs and now what?
> 
> I'm not saying that using some of SleepyCat's stuff for backend is a bad
> idea, but I'm saying that we shouldn't be relying on it ... add on, yes
> ... exclusive, no ...

We could get perpetual rights to the code as integrated into our code. 
Also, if they change something, we could always take it as our own and
keep it working for us.  I think we would need something like that.

It sort of goes to how open we are.  Someone can always take PostgreSQL
and create a branch if we do a terrible job.  We would need that
assurance of the Sleepycat DB.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 15 May 2000 14:09:47 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Proposal: replace no-overwrite with Berkeley DB
>
>We could get perpetual rights to the code as integrated into our code. 
>Also, if they change something, we could always take it as our own and
>keep it working for us.  I think we would need something like that.
>

One of the often-stated virtues of PGSQL is that it is easy for a company
to take the source and go commercial. If you start integrating 'special
license greements' into the development, then that advantage is severly
reduced. 

A commercial operator has to form an agreement with sleepycat or rewrite
the storage manager. Unless sleepycat grant a completely open license to
PGSQL and all it's commercial descendants in perpetuity, it seems you may
be removing one of the seeling points of PGSQL.


----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.C.N. 008 659 498)             |          /(@)   ______---_
Tel: +61-03-5367 7422            |                 _________  \
Fax: +61-03-5367 7430            |                 ___________ |
Http://www.rhyme.com.au          |                /           \|
                                 |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/

Tue, 16 May 2000 10:02:19 +1000
Philip Warner <pjw@rhyme.com.au>
Re: Proposal: replace no-overwrite with Berkeley DB
> >
> >We could get perpetual rights to the code as integrated into our code. 
> >Also, if they change something, we could always take it as our own and
> >keep it working for us.  I think we would need something like that.
> >
> 
> One of the often-stated virtues of PGSQL is that it is easy for a company
> to take the source and go commercial. If you start integrating 'special
> license greements' into the development, then that advantage is severly
> reduced. 
> 
> A commercial operator has to form an agreement with sleepycat or rewrite
> the storage manager. Unless sleepycat grant a completely open license to
> PGSQL and all it's commercial descendants in perpetuity, it seems you may
> be removing one of the seeling points of PGSQL.

Yes, something like this would be required.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 15 May 2000 20:27:49 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Proposal: replace no-overwrite with Berkeley DB