Re: Berkeley DB license

"Michael A. Olson" <mao@sleepycat.com> writes:
> Let's hold the legal discussion until we decide whether we need to have
> it at all.

Seems to me that Mike has stated that Sleepycat is willing to do what
they have to do to meet our requirements that Postgres remain completely
free.  Let's take that as read for the moment and pay more attention to
the technical issues.  As he says, if there are technical showstoppers
then there's no point in haggling over license wording.  We can come
back to the legal details when and if we decide that the idea looks
like a good one technically.

I'm going to be extremely presumptive here and try to push the technical
discussion into several specific channels.  It looks to me like we've
got four major areas of concern technically:

1. MVCC semantics.  If we can't keep MVCC then the deal's dead in the
water, no question.  Vadim's by far the best man to look at this issue;
Vadim, do you have time to think about it soon?

2. Where to draw the API line.  Berkeley DB's API doesn't seem to fit
very neatly into the existing modularization of Postgres.  How should
we approach that, and how much work would it cost us?  Are there parts
of BDB that we just don't want to use at all?

3. Additional access methods.  Mike thinks we could live with using
BDB's Recno access method for primary heap storage.  I'm dubious
(OK, call me stubborn...).  We also have index methods that BDB hasn't
got.  I'm not sure that our GIST code is being used or is even
functional, but the rtree code has certainly got users.  So, how hard
might it be to add raw-heap and rtree access methods to BDB?

4. What are we buying for the above work?  With all due respect to
Mike, he's said that he hasn't looked at the Postgres code since it
was in Berkeley's hands.  We've made some considerable strides since
then, and maybe moving to BDB wouldn't be as big a win as he thinks.
On the other hand, Vadim is about to invest a great deal of work
in WAL+new smgr; maybe we'd get more bang for the buck by putting
the same amount of effort into interfacing to BDB.  We've got to
look hard at this.

Anyone see any major points that I've missed here?

How can we move forward on looking at these questions?  Seems like
we ought to try for the "quick kill": if anyone can identify any
clear showstoppers in any of these areas, nailing down any one will
end the discussion.  As long as we don't find a showstopper it seems
that we ought to keep talking about it.
        regards, tom lane