Thread: Oracle purchases Sleepycat - is this the "other shoe" for MySQL AB?

Oracle purchases Sleepycat.  From what I understand, BerkeleyDB was the
"other" way that MySQL could have transactions if Oracle decided to
restrict InnoDB tables (after purchasing Innobase last year).

Does this mean the other shoe has dropped for MySQL AB?

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

On Tue, 14 Feb 2006, Randal L. Schwartz wrote:

> Oracle purchases Sleepycat.  From what I understand, BerkeleyDB was the
> "other" way that MySQL could have transactions if Oracle decided to
> restrict InnoDB tables (after purchasing Innobase last year).

   From what I read a few days ago, Oracle is negotiating with Sleepycat, Zope
(is that the PHP developer's name?), and one other OSS developer. Nothing is
yet signed, and they could all fall through.

Rich

--
Richard B. Shepard, Ph.D.               |   Author of "Quantifying Environmental
Applied Ecosystem Services, Inc. (TM)   |  Impact Assessments Using Fuzzy Logic"
<http://www.appl-ecosys.com>     Voice: 503-667-4517         Fax: 503-667-8863

Rich Shepard wrote:
> On Tue, 14 Feb 2006, Randal L. Schwartz wrote:
>
>> Oracle purchases Sleepycat.  From what I understand, BerkeleyDB was the
>> "other" way that MySQL could have transactions if Oracle decided to
>> restrict InnoDB tables (after purchasing Innobase last year).
>
>   From what I read a few days ago, Oracle is negotiating with
> Sleepycat, Zope
> (is that the PHP developer's name?), and one other OSS developer.
> Nothing is
> yet signed, and they could all fall through.
>
> Rich
>

Zope is a Python  framework
Zend is for  php

leonel

On Tue, 2006-02-14 at 10:51, Leonel Nunez wrote:
> Rich Shepard wrote:
> > On Tue, 14 Feb 2006, Randal L. Schwartz wrote:
> >
> >> Oracle purchases Sleepycat.  From what I understand, BerkeleyDB was the
> >> "other" way that MySQL could have transactions if Oracle decided to
> >> restrict InnoDB tables (after purchasing Innobase last year).
> >
> >   From what I read a few days ago, Oracle is negotiating with
> > Sleepycat, Zope
> > (is that the PHP developer's name?), and one other OSS developer.
> > Nothing is
> > yet signed, and they could all fall through.
> >
> > Rich
> >
>
> Zope is a Python  framework
> Zend is for  php

Also, given the license of PHP, which is NOT like the GPL, but much
closer to the BSD license, I doubt Oracle could manage to buy it and
kill it or hide it or whatever.

merlyn@stonehenge.com (Randal L. Schwartz) writes:
> Oracle purchases Sleepycat.  From what I understand, BerkeleyDB was the
> "other" way that MySQL could have transactions if Oracle decided to
> restrict InnoDB tables (after purchasing Innobase last year).

> Does this mean the other shoe has dropped for MySQL AB?

The deal's not gone through yet, but it sure does look like they want to
put a hammerlock on MySQL ...

            regards, tom lane

On Tue, 14 Feb 2006, Scott Marlowe wrote:

> On Tue, 2006-02-14 at 10:51, Leonel Nunez wrote:
>> Rich Shepard wrote:
>>> On Tue, 14 Feb 2006, Randal L. Schwartz wrote:
>>>
>>>> Oracle purchases Sleepycat.  From what I understand, BerkeleyDB was the
>>>> "other" way that MySQL could have transactions if Oracle decided to
>>>> restrict InnoDB tables (after purchasing Innobase last year).
>>>
>>>   From what I read a few days ago, Oracle is negotiating with
>>> Sleepycat, Zope
>>> (is that the PHP developer's name?), and one other OSS developer.
>>> Nothing is
>>> yet signed, and they could all fall through.
>>>
>>> Rich
>>>
>>
>> Zope is a Python  framework
>> Zend is for  php
>
> Also, given the license of PHP, which is NOT like the GPL, but much
> closer to the BSD license, I doubt Oracle could manage to buy it and
> kill it or hide it or whatever.

As of this moment, if Oracle buys Zend, they could effectively kill PHP
... the core engine that PHP is built around is a Zend engine, so if they
were to revoke the license for that, PHP would be dead ... kinda like
MySQL with InnoDB ... now, there was talk at one point time with
replacying that engine with Parrot, so I'm not sure how hard/long it would
take for them to do so if Zend got pulled out from under them ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Marc G. Fournier wrote:
> On Tue, 14 Feb 2006, Scott Marlowe wrote:
>
>> On Tue, 2006-02-14 at 10:51, Leonel Nunez wrote:
>>> Rich Shepard wrote:
>>>> On Tue, 14 Feb 2006, Randal L. Schwartz wrote:
>>>>
>>>>> Oracle purchases Sleepycat.  From what I understand, BerkeleyDB was
>>>>> the
>>>>> "other" way that MySQL could have transactions if Oracle decided to
>>>>> restrict InnoDB tables (after purchasing Innobase last year).
>>>>
>>>>   From what I read a few days ago, Oracle is negotiating with
>>>> Sleepycat, Zope
>>>> (is that the PHP developer's name?), and one other OSS developer.
>>>> Nothing is
>>>> yet signed, and they could all fall through.
>>>>
>>>> Rich
>>>>
>>>
>>> Zope is a Python  framework
>>> Zend is for  php
>>
>> Also, given the license of PHP, which is NOT like the GPL, but much
>> closer to the BSD license, I doubt Oracle could manage to buy it and
>> kill it or hide it or whatever.
>
> As of this moment, if Oracle buys Zend, they could effectively kill PHP
> ... the core engine that PHP is built around is a Zend engine, so if
> they were to revoke the license for that, PHP would be dead ... kinda
> like MySQL with InnoDB ... now, there was talk at one point time with
> replacying that engine with Parrot, so I'm not sure how hard/long it
> would take for them to do so if Zend got pulled out from under them ...
>
> ----
> Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
> Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
>               http://archives.postgresql.org
>
Why not replace the whole of PHP/mySQL with Whitebeam(unashamed plug)/PostgreSQL,
have a complete BSD licensed solution and avoid all this uncertainty :-) ?

--
Peter Wilson
http://www.whitebeam.org
http://www.yellowhawk.co.uk
--------

* Marc G. Fournier (scrappy@postgresql.org) wrote:
> As of this moment, if Oracle buys Zend, they could effectively kill PHP
> ... the core engine that PHP is built around is a Zend engine, so if they
> were to revoke the license for that, PHP would be dead ... kinda like
> MySQL with InnoDB ... now, there was talk at one point time with
> replacying that engine with Parrot, so I'm not sure how hard/long it would
> take for them to do so if Zend got pulled out from under them ...

Has there been any actual test (ie: court case) of a piece of software
being released under an open source (BSD, GPL, whatever) license and
then the licensor revoking that and stopping everyone from distributing
the code?  Personally, I have no idea at all if this is something which
can be done and upheld or not and I'm kind of curious about it.  That
would be a very different (and much more difficult for the rest of us)
situation from releasing future versions as closed-source only or just
not releasing new versions.

    Thanks,

        Stephen

Tom Lane wrote:
> merlyn@stonehenge.com (Randal L. Schwartz) writes:
>> Oracle purchases Sleepycat.  From what I understand, BerkeleyDB was the
>> "other" way that MySQL could have transactions if Oracle decided to
>> restrict InnoDB tables (after purchasing Innobase last year).
>
>> Does this mean the other shoe has dropped for MySQL AB?
>
> The deal's not gone through yet, but it sure does look like they want to
> put a hammerlock on MySQL ...

Oracle claims it has (has anyone been contacted by Oracle about PG :)?):

http://www.informationweek.com/software/showArticle.jhtml?articleID=180200853&subSection=Open+Source
--
Steve Wampler -- swampler@noao.edu
The gods that smiled on your birth are now laughing out loud.

On Tue, 14 Feb 2006, Stephen Frost wrote:

> * Marc G. Fournier (scrappy@postgresql.org) wrote:
>> As of this moment, if Oracle buys Zend, they could effectively kill PHP
>> ... the core engine that PHP is built around is a Zend engine, so if they
>> were to revoke the license for that, PHP would be dead ... kinda like
>> MySQL with InnoDB ... now, there was talk at one point time with
>> replacying that engine with Parrot, so I'm not sure how hard/long it would
>> take for them to do so if Zend got pulled out from under them ...
>
> Has there been any actual test (ie: court case) of a piece of software
> being released under an open source (BSD, GPL, whatever) license and
> then the licensor revoking that and stopping everyone from distributing
> the code?  Personally, I have no idea at all if this is something which
> can be done and upheld or not and I'm kind of curious about it.  That
> would be a very different (and much more difficult for the rest of us)
> situation from releasing future versions as closed-source only or just
> not releasing new versions.

Actually, based on my limited understanding ... "currently existing
versions" of PHP would be safe, it would be new versions that would have
to rip out the Zend stuff ... I don't believe you can retroactively change
a license, but IANAL ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

At 2:15 PM -0400 2/14/06, Marc G. Fournier wrote:
>On Tue, 14 Feb 2006, Scott Marlowe wrote:
>
>>On Tue, 2006-02-14 at 10:51, Leonel Nunez wrote:
>>>Rich Shepard wrote:
>>>>On Tue, 14 Feb 2006, Randal L. Schwartz wrote:
>>>>
>>>>>Oracle purchases Sleepycat.  From what I understand, BerkeleyDB was the
>>>>>"other" way that MySQL could have transactions if Oracle decided to
>>>>>restrict InnoDB tables (after purchasing Innobase last year).
>>>>
>>>>   From what I read a few days ago, Oracle is negotiating with
>>>>Sleepycat, Zope
>>>>(is that the PHP developer's name?), and one other OSS developer.
>>>>Nothing is
>>>>yet signed, and they could all fall through.
>>>>
>>>>Rich
>>>>
>>>
>>>Zope is a Python  framework
>>>Zend is for  php
>>
>>Also, given the license of PHP, which is NOT like the GPL, but much
>>closer to the BSD license, I doubt Oracle could manage to buy it and
>>kill it or hide it or whatever.
>
>As of this moment, if Oracle buys Zend, they could effectively kill
>PHP ... the core engine that PHP is built around is a Zend engine,
>so if they were to revoke the license for that, PHP would be dead
>... kinda like MySQL with InnoDB ... now, there was talk at one
>point time with replacying that engine with Parrot, so I'm not sure
>how hard/long it would take for them to do so if Zend got pulled out
>from under them ...

Zend isn't, last time I looked (which, granted, was ages ago), needed
to run PHP, but it may be now. The license that's in php 5.1.2 makes
it look like, while you might have some naming problems, php would be
safely available regardless of what anyone might do to the Zend
people.

Parrot was certainly functionally up for running PHP last summer, and
it seems unlikely that it's not still ready. (Granted, someone would
still have to write any libraries that PHP provides that aren't
written in PHP, and write a simple compiler for it, so it wouldn't
happen tomorrow, but it's certainly doable)
--
                Dan

--------------------------------------it's like this-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk

* Marc G. Fournier (scrappy@postgresql.org) wrote:
> On Tue, 14 Feb 2006, Stephen Frost wrote:
> >Has there been any actual test (ie: court case) of a piece of software
> >being released under an open source (BSD, GPL, whatever) license and
> >then the licensor revoking that and stopping everyone from distributing
> >the code?  Personally, I have no idea at all if this is something which
> >can be done and upheld or not and I'm kind of curious about it.  That
> >would be a very different (and much more difficult for the rest of us)
> >situation from releasing future versions as closed-source only or just
> >not releasing new versions.
>
> Actually, based on my limited understanding ... "currently existing
> versions" of PHP would be safe, it would be new versions that would have
> to rip out the Zend stuff ... I don't believe you can retroactively change
> a license, but IANAL ...

Well, if you can't retroactively change a license then couldn't the
existing version of Zend also be used going forward...?  It wouldn't
need to be ripped out...  (Perhaps I'm missing something here but I'm
guessing the Zend stuff is under an open source license atm too...).

    Thanks,

        Stephen

Stephen Frost <sfrost@snowman.net> writes:
> Has there been any actual test (ie: court case) of a piece of software
> being released under an open source (BSD, GPL, whatever) license and
> then the licensor revoking that and stopping everyone from distributing
> the code?

AFAIK it's not possible to revoke privileges already granted.  The
reason that Oracle's moves are potentially serious is that there is a
fairly small developer base for the bits of software in question, and
they could effectively lock up the knowledge needed to do anything
useful (eg, by enforcing noncompete agreements that probably already
exist for the employees of the companies they're buying).  Thus,
even though the user communities of these packages have the legal right
to maintain a GPL-license fork, they might be years away from having
the technical competence to do anything very useful with them.  (Look
at how long it took us to get far with the PG codebase after Berkeley
handed it over.)  Plus there's the problem of re-coalescing the
community around a new core team that doesn't exist ...

            regards, tom lane

On Tue, 2006-02-14 at 12:54, Marc G. Fournier wrote:
> On Tue, 14 Feb 2006, Stephen Frost wrote:
>
> > * Marc G. Fournier (scrappy@postgresql.org) wrote:
> >> As of this moment, if Oracle buys Zend, they could effectively kill PHP
> >> ... the core engine that PHP is built around is a Zend engine, so if they
> >> were to revoke the license for that, PHP would be dead ... kinda like
> >> MySQL with InnoDB ... now, there was talk at one point time with
> >> replacying that engine with Parrot, so I'm not sure how hard/long it would
> >> take for them to do so if Zend got pulled out from under them ...
> >
> > Has there been any actual test (ie: court case) of a piece of software
> > being released under an open source (BSD, GPL, whatever) license and
> > then the licensor revoking that and stopping everyone from distributing
> > the code?  Personally, I have no idea at all if this is something which
> > can be done and upheld or not and I'm kind of curious about it.  That
> > would be a very different (and much more difficult for the rest of us)
> > situation from releasing future versions as closed-source only or just
> > not releasing new versions.
>
> Actually, based on my limited understanding ... "currently existing
> versions" of PHP would be safe, it would be new versions that would have
> to rip out the Zend stuff ... I don't believe you can retroactively change
> a license, but IANAL ...

Nope.  The ZEND license reads pretty much like a BSD license.  "You got
it, it's yours, feel free to do what you want with it, as long as you
acknowledge you got it from us."

So, new versions of PHP could certainly be built on top of Zend, and if
someone found a bug in Zend, then they could fix it and release that
improved version.  As long as they followed the license given to them.

Again, the MySQL thing is very different from most other situations, and
it's different BECAUSE MySQL AB plays the dual license game but they
don't own all the code they dual license.

merlyn@stonehenge.com (Randal L. Schwartz) writes:
> Oracle purchases Sleepycat.  From what I understand, BerkeleyDB was the
> "other" way that MySQL could have transactions if Oracle decided to
> restrict InnoDB tables (after purchasing Innobase last year).
>
> Does this mean the other shoe has dropped for MySQL AB?

This assumes that the MySQL AB plan was to have the "new transaction
engine" be based on Sleepycat DB.

There was certainly plenty of speculation that assumed that, but I
don't recall seeing anything actually said by principals of MySQL AB
to that effect...
--
output = ("cbbrowne" "@" "ntlug.org")
http://www3.sympatico.ca/cbbrowne/finances.html
A  student,  in hopes  of  understanding  the  Lambda-nature, came  to
Greenblatt.  As they spoke a  Multics system hacker walked by.  "Is it
true", asked the  student, "that PL-1 has many of  the same data types
as  Lisp?"   Almost before  the  student  had  finished his  question,
Greenblatt shouted, "FOO!", and hit the student with a stick.

Chris Browne wrote:
> This assumes that the MySQL AB plan was to have the "new transaction
> engine" be based on Sleepycat DB.
>
> There was certainly plenty of speculation that assumed that, but I
> don't recall seeing anything actually said by principals of MySQL AB
> to that effect...

http://dev.mysql.com/doc/refman/5.1/en/bdb-storage-engine.html

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

The rumor wrt to buying sleepycat is true.

http://www.oracle.com/corporate/press/2006_feb/sleepycat.html

--elein


On Tue, Feb 14, 2006 at 08:32:00AM -0800, Rich Shepard wrote:
> On Tue, 14 Feb 2006, Randal L. Schwartz wrote:
>
> >Oracle purchases Sleepycat.  From what I understand, BerkeleyDB was the
> >"other" way that MySQL could have transactions if Oracle decided to
> >restrict InnoDB tables (after purchasing Innobase last year).
>
>   From what I read a few days ago, Oracle is negotiating with Sleepycat,
>   Zope
> (is that the PHP developer's name?), and one other OSS developer. Nothing is
> yet signed, and they could all fall through.
>
> Rich
>
> --
> Richard B. Shepard, Ph.D.               |   Author of "Quantifying
> Environmental
> Applied Ecosystem Services, Inc. (TM)   |  Impact Assessments Using Fuzzy
> Logic"
> <http://www.appl-ecosys.com>     Voice: 503-667-4517         Fax:
> 503-667-8863
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>       choose an index scan if your joining column's datatypes do not
>       match
>

On Tue, Feb 14, 2006 at 02:00:13PM -0500, Tom Lane wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > Has there been any actual test (ie: court case) of a piece of software
> > being released under an open source (BSD, GPL, whatever) license and
> > then the licensor revoking that and stopping everyone from distributing
> > the code?
>
> AFAIK it's not possible to revoke privileges already granted.  The
> reason that Oracle's moves are potentially serious is that there is a
> fairly small developer base for the bits of software in question, and
> they could effectively lock up the knowledge needed to do anything
> useful (eg, by enforcing noncompete agreements that probably already
> exist for the employees of the companies they're buying).  Thus,
> even though the user communities of these packages have the legal right
> to maintain a GPL-license fork, they might be years away from having
> the technical competence to do anything very useful with them.  (Look
> at how long it took us to get far with the PG codebase after Berkeley
> handed it over.)  Plus there's the problem of re-coalescing the
> community around a new core team that doesn't exist ...
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match
>

Not just non-compete agreements, but purchasing of employees with
the knowledge base is how it works.  That is what Informix did with
Illustra--it bought the engineers.  Sleepycat people are probably
tied up with golden handcuffs--corporate kink ;)

--elein
elein@varlena.com

On 2/14/06, Dan Sugalski <dan@sidhe.org> wrote:
> Zend isn't, last time I looked (which, granted, was ages ago), needed
> to run PHP, but it may be now.

I guess you are thinking about "Zend - PHP Optimizer" not "Zend - PHP Core".

--
marko

At 11:16 PM +0200 2/14/06, Marko Kreen wrote:
>On 2/14/06, Dan Sugalski <dan@sidhe.org> wrote:
>>  Zend isn't, last time I looked (which, granted, was ages ago), needed
>>  to run PHP, but it may be now.
>
>I guess you are thinking about "Zend - PHP Optimizer" not "Zend - PHP Core".

Yeah. The core falls under the basic PHP license, which isn't
yankable unless there's some bizarre, gross, and egregious negligence
on the part of an awful lot of people. (in which case arguably it
ought to be brought to light anyway, though I don't know that I'd
want to be the one arguing it)
--
                Dan

--------------------------------------it's like this-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk

Marc G. Fournier wrote:
> As of this moment, if Oracle buys Zend, they could effectively kill PHP
> ... the core engine that PHP is built around is a Zend engine, so if
> they were to revoke the license for that, PHP would be dead ... kinda
> like MySQL with InnoDB ... now, there was talk at one point time with
> replacying that engine with Parrot, so I'm not sure how hard/long it
> would take for them to do so if Zend got pulled out from under them ...

FWIW, I know that Yahoo began quietly (though not quietly enough,
obviously) organizing an Open PHP dev group a couple of years ago with
the purpose of replacing the proprietary Zend engine.

Steve Manes wrote:
> Marc G. Fournier wrote:
>> As of this moment, if Oracle buys Zend, they could effectively kill
>> PHP ... the core engine that PHP is built around is a Zend engine, so
>> if they were to revoke the license for that, PHP would be dead ...
>> kinda like MySQL with InnoDB ... now, there was talk at one point
>> time with replacying that engine with Parrot, so I'm not sure how
>> hard/long it would take for them to do so if Zend got pulled out from
>> under them ...
>
> FWIW, I know that Yahoo began quietly (though not quietly enough,
> obviously) organizing an Open PHP dev group a couple of years ago with
> the purpose of replacing the proprietary Zend engine.
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
A secret Open group  I like it!

Sorry for spamming I couldn't resist,
Oisin

I am not concerned about Sleepycat revoking their open source license
for future versions of BDB. I am less concerned about them revoking
licenses for current and older releases. That would be impossible.
However this "deal" troubles me and I cant quite put my finger on why.
I'll try to tease it out. Please bear with me.

As I understand it Sleepycat make most of their money by selling
commercial licenses to companies who use their stuff but who don't want
to open source their own code. Companies such as these will in the
future be required to talk to Oracle to negotiate a new license. So far
nothing sinister about this.

However, I see MySQL as the future losers here. I cannot see why else
Oracle would buy both of the MySQL storage engines other than to
effectively remove both of them from the MySLQ product suite in future
releases, thereby weakening it. Im just wondering how they are going to
achieve it though. According to Olson, BDB will still be available
under the dual license. Lets assume for the moment that at least the
open source license will still be available. Happy days, unless of
course the product you own is called "MySQL". Do MySQL or any MySQL
customers need a commercial license for BDB? I think not. MySQL does
not as all its code is open source. As for MySQL customers, unless they
are making direct API calls into BDB (which most don't) I don't think
they are categorized as BDB Api users and so can keep their code
proprietary without having to answer to Sleepycat/Oracle for a
commercial license.

Therefore I see only the following mechanisms for Oracle to remove BDB
from MySQL
1. Discontinue BDB
2. "Change their mind" about free licensing and start charging
exorbidant fees for use of BDB, regardless of the type of application
3. And I feel if 1 and 2 do not happen then this is the highly
probably: use a non-compete clause in the BDB license to effectively
prevent companies like MySQL ever licensing BDB again. Sleepycat have a
similar clause in their own license to prevent companies releasing
products using BDB which could be seen to compete with Sleepycat. This
clause will change to refer to Oracle instead of Sleepycat. I hasten to
add this non-compete clause only refers to non-open source applications
today. This will signal the end of relationship between MySQL and BDB.
Question is: can they put non-compete clauses into open source
licenses? I dont think so. Maybe Oracle will just proceed with step 2,
first. Either way there is no way Oracle will allow to continue the
situation where MySQL gets to use BDB, a world class storage engine for
FREE, as they happily steal customers from Oracle the very company that
now owns said engine.

As of today I consider myself to be an EX-Berkeley DB user/developer.
What we need now is an open source DB with clean APIs into various
places in the software stack (eg we need a Berkeley DB kind of API
under the hood into something like Postgres) A full bells and whistles
relational DB with these low level ACCESS APIs will be a powerfull
thing in the future. PostgreSQL take note. If you don't already have it
you should begin exposing such a thing today in my humble opinion.

Being part of a big company changes you. This deal may stifle
innovation in BDB going forward. If so there is an opportunity to fill
that gap. I turn to the PostgreSQL community to rise to the challenge.

On Wed, 2006-02-15 at 11:05, Chad wrote:
> I am not concerned about Sleepycat revoking their open source license
> for future versions of BDB. I am less concerned about them revoking
> licenses for current and older releases. That would be impossible.
> However this "deal" troubles me and I cant quite put my finger on why.
> I'll try to tease it out. Please bear with me.
>
> As I understand it Sleepycat make most of their money by selling
> commercial licenses to companies who use their stuff but who don't want
> to open source their own code. Companies such as these will in the
> future be required to talk to Oracle to negotiate a new license. So far
> nothing sinister about this.
>
> However, I see MySQL as the future losers here. I cannot see why else
> Oracle would buy both of the MySQL storage engines other than to
> effectively remove both of them from the MySLQ product suite in future
> releases, thereby weakening it. Im just wondering how they are going to
> achieve it though. According to Olson, BDB will still be available
> under the dual license. Lets assume for the moment that at least the
> open source license will still be available. Happy days, unless of
> course the product you own is called "MySQL". Do MySQL or any MySQL
> customers need a commercial license for BDB? I think not. MySQL does
> not as all its code is open source.

Here's where I think you misunderstand how MySQL AB's business model
works.  MySQL AB sell a GPL database.  The connection libs are GPL.  If
you write code that connects to their database through their connection
libs, you have two options:  1:  Write GPL code.  Note that there's an
exception for PHP code.  I'll assume you're talking about folks writing
in C or something.  2:  Buy a commercial license from MySQL for each
copy you sell / distribute by means other than the GPL.

So, it's source code is not Open Source, as the OSI defines it, it is
Free Software, as RMS and friends define it, and it is VERY viral if you
use it as such.  Basically, either you write GPL code, or you buy a
commercial license.

Randal L. Schwartz wrote:
> Oracle purchases Sleepycat.  From what I understand, BerkeleyDB was the
> "other" way that MySQL could have transactions if Oracle decided to
> restrict InnoDB tables (after purchasing Innobase last year).
>
> Does this mean the other shoe has dropped for MySQL AB?
>
I think the thing being missed in all this isn't the impact of Oracle
buying innodb and sleepycat on open-source mySQL. The open-source license
for existing versions of this code I believe cannot be revoked - and
if Oracle tried it they would get a ridiculous amount of bad press.

Assuming Oracle are making these purchase to 'get at' mySql then why?

One thing it does do is give them the power to squeeze mySQLs business
model - the one where they make money out of their commercial license
for their database. The open-source version doesn't directly make money
for the company - instead you are encouraged to buy a commercial license
for that.

To do a commercial license for mySQL the company has to negotiate a
commercial licence for innodb and berkley DB. they have to pay those
companies. The agreements are probably periodically re-negotiated (I
seem to remember something about this when innodb were acquired).

When it's time to renegotiate Oracle could say add a (modest) 10-15-25%
onto the cost. mySql then have a problem - they pass that cost onto
their customers and probably loose a number of them to the open-source
version, or they swallow the cost. Either way that reduces the
amount of revenue they make. Less revenue means less resource to improve
mySql - in the worst case mySql have to use all their revenue to
support existing releases.

Stunting mySql development resource means less new features and keeps a
healthy functional gap between 'Enterprise class DB' Oracle and 'poor mans
option' of mySql. The bigger Oracle can keep that gap the fewer Enterprise
customers they loose to mySql.

Of course that can then all be offset by a knight in shining armour that,
for their own reasons, decide to donate some money or resource to mySql.

ho-hum - conspiracy theories abound!

Just about the only thing that can be said is that Oracle doesn't
need the technology they have bought!

my t'pennyw'th

Pete
--
http://www.whitebeam.org - open source web application server
----

On Feb 14, 2006, at 3:45 PM, Peter Eisentraut wrote:

> http://dev.mysql.com/doc/refman/5.1/en/bdb-storage-engine.html

For kicks, I decided to read that... lead me to this page:

http://dev.mysql.com/doc/refman/5.1/en/bdb-restrictions.html

I especially like the third restriction.  How on earth do people live
with this software?

Vivek Khera <vivek@khera.org> writes:
> http://dev.mysql.com/doc/refman/5.1/en/bdb-restrictions.html

> I especially like the third restriction.  How on earth do people live
> with this software?

The preceding page is amusing too:
http://dev.mysql.com/doc/refman/5.1/en/bdb-todo.html

I find this important TODO item particularly telling:
    * Change to use no page locks for table scanning operations.
Maybe I'm misunderstanding, but that sure sounds like they intend to
dumb down BDB so that it no longer works well in concurrent situations,
in order to save a few cycles in single-user scenarios.  Have MySQL
officially abandoned the multi-user case to us?

            regards, tom lane

>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:

Tom>     * Change to use no page locks for table scanning operations.
Tom> Maybe I'm misunderstanding, but that sure sounds like they intend to
Tom> dumb down BDB so that it no longer works well in concurrent situations,
Tom> in order to save a few cycles in single-user scenarios.  Have MySQL
Tom> officially abandoned the multi-user case to us?

What they lose in usability, they gain back in benchmarks, and that's
all that matters: getting the wrong answer really fast.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Well, in all fairness, MySQL probably gives the right answer most of the time,
always really fast (except for some use cases).

On Wed, 15 Feb 2006, Randal L. Schwartz wrote:

>>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>
> Tom>     * Change to use no page locks for table scanning operations.
> Tom> Maybe I'm misunderstanding, but that sure sounds like they intend to
> Tom> dumb down BDB so that it no longer works well in concurrent situations,
> Tom> in order to save a few cycles in single-user scenarios.  Have MySQL
> Tom> officially abandoned the multi-user case to us?
>
> What they lose in usability, they gain back in benchmarks, and that's
> all that matters: getting the wrong answer really fast.
>
> --
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
> <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
> See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
>               http://archives.postgresql.org
>

On Wed, Feb 15, 2006 at 01:02:03PM -0800, Ben wrote:
> Well, in all fairness, MySQL probably gives the right answer most of the
> time, always really fast (except for some use cases).

"Probably gives the right answer most of the time."

I'm not sure whether to laugh or cry.

--
Michael Fuhr

Why doesn't mysql just forget the whole dual licensing of the server
thing and just tell everyone to use the GPL versions of everything.
Then dual license the client libraries which I would think they
already own outright.  I think this is what forces most people to
need a commercial license.  Do most of their customers really need to
modify the server?

The other thing that most of their customers probably need is just a
support contract in case something goes wrong and to keep the bosses
happy.  And that is not really something that oracle can interfere
with (unless they try to buy off all of their employees individually).

Of course they should all just switch to postgres anyway but that is
another story.  :)

Rick


On Feb 15, 2006, at 10:05 AM, Chad wrote:

> I am not concerned about Sleepycat revoking their open source license
> for future versions of BDB. I am less concerned about them revoking
> licenses for current and older releases. That would be impossible.
> However this "deal" troubles me and I cant quite put my finger on why.
> I'll try to tease it out. Please bear with me.
>
> As I understand it Sleepycat make most of their money by selling
> commercial licenses to companies who use their stuff but who don't
> want
> to open source their own code. Companies such as these will in the
> future be required to talk to Oracle to negotiate a new license. So
> far
> nothing sinister about this.
>
> However, I see MySQL as the future losers here. I cannot see why else
> Oracle would buy both of the MySQL storage engines other than to
> effectively remove both of them from the MySLQ product suite in future
> releases, thereby weakening it. Im just wondering how they are
> going to
> achieve it though. According to Olson, BDB will still be available
> under the dual license. Lets assume for the moment that at least the
> open source license will still be available. Happy days, unless of
> course the product you own is called "MySQL". Do MySQL or any MySQL
> customers need a commercial license for BDB? I think not. MySQL does
> not as all its code is open source. As for MySQL customers, unless
> they
> are making direct API calls into BDB (which most don't) I don't think
> they are categorized as BDB Api users and so can keep their code
> proprietary without having to answer to Sleepycat/Oracle for a
> commercial license.
>
> Therefore I see only the following mechanisms for Oracle to remove BDB
> from MySQL
> 1. Discontinue BDB
> 2. "Change their mind" about free licensing and start charging
> exorbidant fees for use of BDB, regardless of the type of application
> 3. And I feel if 1 and 2 do not happen then this is the highly
> probably: use a non-compete clause in the BDB license to effectively
> prevent companies like MySQL ever licensing BDB again. Sleepycat
> have a
> similar clause in their own license to prevent companies releasing
> products using BDB which could be seen to compete with Sleepycat. This
> clause will change to refer to Oracle instead of Sleepycat. I
> hasten to
> add this non-compete clause only refers to non-open source
> applications
> today. This will signal the end of relationship between MySQL and BDB.
> Question is: can they put non-compete clauses into open source
> licenses? I dont think so. Maybe Oracle will just proceed with step 2,
> first. Either way there is no way Oracle will allow to continue the
> situation where MySQL gets to use BDB, a world class storage engine
> for
> FREE, as they happily steal customers from Oracle the very company
> that
> now owns said engine.
>
> As of today I consider myself to be an EX-Berkeley DB user/developer.
> What we need now is an open source DB with clean APIs into various
> places in the software stack (eg we need a Berkeley DB kind of API
> under the hood into something like Postgres) A full bells and whistles
> relational DB with these low level ACCESS APIs will be a powerfull
> thing in the future. PostgreSQL take note. If you don't already
> have it
> you should begin exposing such a thing today in my humble opinion.
>
> Being part of a big company changes you. This deal may stifle
> innovation in BDB going forward. If so there is an opportunity to fill
> that gap. I turn to the PostgreSQL community to rise to the challenge.
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
>                http://www.postgresql.org/docs/faq
>

Quoth rick@alpinenetworking.com (Rick Gigger):
> Why doesn't mysql just forget the whole dual licensing of the server
> thing and just tell everyone to use the GPL versions of everything.
> Then dual license the client libraries which I would think they
> already own outright.  I think this is what forces most people to
> need a commercial license.  Do most of their customers really need
> to modify the server?

Ah, but that would shoot their funding model in the head, and the
Vulture Capital guys that invested ~$19M in them wouldn't be terribly
happy about them throwing away the potential for profitability.

> The other thing that most of their customers probably need is just a
> support contract in case something goes wrong and to keep the bosses
> happy.  And that is not really something that oracle can interfere
> with (unless they try to buy off all of their employees
> individually).

Yeah, but that's not the easy sale.

The easy sale is...

  "If you are unsure, we recommend that you buy our cost effective
  commercial licenses. That is the safest solution."

Which encourages people to pay their $595 per server per year.
--
"cbbrowne","@","gmail.com"
http://linuxfinances.info/info/slony.html
It is interesting to note that before the advent of Microsoft Windows,
`GPF' was better known for  its usage in plumbing: "Gallons Per Flush"
-- dedmonds@aw.sgi.com (Dean Edmonds)

On Wednesday 15 February 2006 01:38, Tom Lane wrote:
> merlyn@stonehenge.com (Randal L. Schwartz) writes:
> > Oracle purchases Sleepycat.  From what I understand, BerkeleyDB was the
> > "other" way that MySQL could have transactions if Oracle decided to
> > restrict InnoDB tables (after purchasing Innobase last year).
> >
> > Does this mean the other shoe has dropped for MySQL AB?
>
> The deal's not gone through yet, but it sure does look like they want to
> put a hammerlock on MySQL ...

Is it possible that Oracle is trying to buy MySQL to kill off other open
source competitor, e.g. PostgreSQL?  MySQL has a strong number of users and
therefore it is a good deal for Oracle to buy MySQL.  Then by doing that,
Oracle will market MySQL as the low-end alternative to their own database to
give a full solution to the customer.  And this would slow down the take up
rate for other database competitor.

I just hope not....



Regards,

Leonard Soetedjo

On Thu, 16 Feb 2006, Leonard Soetedjo wrote:

> On Wednesday 15 February 2006 01:38, Tom Lane wrote:
>> merlyn@stonehenge.com (Randal L. Schwartz) writes:
>>> Oracle purchases Sleepycat.  From what I understand, BerkeleyDB was the
>>> "other" way that MySQL could have transactions if Oracle decided to
>>> restrict InnoDB tables (after purchasing Innobase last year).
>>>
>>> Does this mean the other shoe has dropped for MySQL AB?
>>
>> The deal's not gone through yet, but it sure does look like they want to
>> put a hammerlock on MySQL ...
>
> Is it possible that Oracle is trying to buy MySQL to kill off other open
> source competitor, e.g. PostgreSQL?  MySQL has a strong number of users and
> therefore it is a good deal for Oracle to buy MySQL.  Then by doing that,
> Oracle will market MySQL as the low-end alternative to their own database to
> give a full solution to the customer.  And this would slow down the take up
> rate for other database competitor.

IMHO, that would be a difficult sell, unless they continue to sink money
into MySQL to close the gap between MySQL and PostgreSQL ... it would be
possible, but it doesn't make a whole lot of sense to me ...

If someone is going to go with MySQL, most of their motivation is going to
be cost based ... selling them on an upgrade to Oracle at how many $10s of
thousand, vs them moving to PostgreSQL at no cost, could still be a hard
sell :(



  ----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

> On Wednesday 15 February 2006 01:38, Tom Lane wrote:
>> merlyn@stonehenge.com (Randal L. Schwartz) writes:
>>> Oracle purchases Sleepycat.  From what I understand, BerkeleyDB was the
>>> "other" way that MySQL could have transactions if Oracle decided to
>>> restrict InnoDB tables (after purchasing Innobase last year).
>>>
>>> Does this mean the other shoe has dropped for MySQL AB?
>>
>> The deal's not gone through yet, but it sure does look like they want to
>> put a hammerlock on MySQL ...
>
> Is it possible that Oracle is trying to buy MySQL to kill off other open
> source competitor, e.g. PostgreSQL?  MySQL has a strong number of users and
> therefore it is a good deal for Oracle to buy MySQL.  Then by doing that,
> Oracle will market MySQL as the low-end alternative to their own database to
> give a full solution to the customer.  And this would slow down the take up
> rate for other database competitor.

I've always thought that mysql has a large number of users because all the
various web apps (guestbooks, forums, blogs, calendars, etc.) were written
with mysql as the backend.  So, average joe who wants a blog is going to
end up using mysql because that's his only *free* choice.

I base this just on my occasional inquiries into such software and how
many of them support mysql and not postgresql.

I would think that if mysql dissappeared all of those applications would
switch to either sqlite or postgresql in a heartbeat.  Some already are...

I also suspect the windows version of mysql had a lot to do with it as
people could run IIS, php, and mysql locally on their desktop for their
development server...


-philip

* Chad (chadzakary@hotmail.com) wrote:
> course the product you own is called "MySQL". Do MySQL or any MySQL
> customers need a commercial license for BDB? I think not. MySQL does
> not as all its code is open source. As for MySQL customers, unless they
> are making direct API calls into BDB (which most don't) I don't think
> they are categorized as BDB Api users and so can keep their code
> proprietary without having to answer to Sleepycat/Oracle for a
> commercial license.

This doesn't quite work, I don't think.  The license the commercial
MySQL customer gets isn't GPL, it's something else.  Whatever that
'something else' is may be incompatible with the BDB license, esp. if
they license it under the GPL for future releases or something.  This
means MySQL can't distribute (sell) that code under a GPL-incompatible
license.

    Enjoy,

        Stephen

Leonard Soetedjo wrote:
> Is it possible that Oracle is trying to buy MySQL to kill off other open
> source competitor, e.g. PostgreSQL?  MySQL has a strong number of users and
> therefore it is a good deal for Oracle to buy MySQL.  Then by doing that,
> Oracle will market MySQL as the low-end alternative to their own database to
> give a full solution to the customer.  And this would slow down the take up
> rate for other database competitor.

If Oracle rebuilt MySQL to provide a seamless, plug-compatible migration
upgrade to Oracle this might be a successful marketing strategy.  But if
a customer had to rebuild his database layer to move up to Oracle from
MySQL, as he currently does, what would be the incentive to use MySQL
over PG?

I suspect that Oracle needs to burn cash and what better way to spend it
than to expand its influence horizontally across its own marketing
space? That juice could come in handy a couple of years down the road.

On Thursday 16 February 2006 10:15, Steve Manes wrote:
> Leonard Soetedjo wrote:
> > Is it possible that Oracle is trying to buy MySQL to kill off other open
> > source competitor, e.g. PostgreSQL?  MySQL has a strong number of users
> > and therefore it is a good deal for Oracle to buy MySQL.  Then by doing
> > that, Oracle will market MySQL as the low-end alternative to their own
> > database to give a full solution to the customer.  And this would slow
> > down the take up rate for other database competitor.
>
> If Oracle rebuilt MySQL to provide a seamless, plug-compatible migration
> upgrade to Oracle this might be a successful marketing strategy.  But if
> a customer had to rebuild his database layer to move up to Oracle from
> MySQL, as he currently does, what would be the incentive to use MySQL
> over PG?

I've used ORM tool (propel) for PHP and it makes changing from MySQL to
PostgreSQL as easy as changing the config from mysql to pgsql.  And I believe
in Java/.NET there is Hibernate and such.  (Of course here I'm assuming that
a lot of projects are done in PHP and Java or .NET, AND they use ORM tools).

Sidetracking a little, I've got to admit that I'm not very sure of the impact
of ORM to databases.  Some OO proponents insist on not using stored procedure
etc. unless there is a compelling reason (e.g. Martin Fowler in his book
Patterns of Enterprise Application Architecture).  So actually a database
like MySQL4 would suffice, as much as I hate to say it.

And since MySQL already has got the upperhand in terms of marketing, Oracle
would buy MySQL to make it as the low-end alternative.  Never mind the
lack/immature features in MySQL such as stored proc or trigger.

Is my argument valid or am I only seeing one side of the coin?


Regards,

Leonard Soetedjo

> And since MySQL already has got the upperhand in terms of marketing, Oracle
> would buy MySQL to make it as the low-end alternative.  Never mind the
> lack/immature features in MySQL such as stored proc or trigger.

Mysql 5 has stored procedures and triggers.

The fact that you have to change between different "storage engines" to
use transactions properly etc is a little weird (and some of the new
engines are just bizarre), but that's beside the point.

90% of open-source software is written to use only mysql (and it's not
easy to switch to another db) - search freshmeat or sourceforge for
anything postgresql related.. not much there.

Then, even if you do write something to use postgresql a lot of hosts
don't support it anyway ('mysql is good enough').. so you're stuck.

On Wednesday 15 February 2006 18:49, Chris wrote:
> > And since MySQL already has got the upperhand in terms of marketing,
> > Oracle would buy MySQL to make it as the low-end alternative.  Never mind
> > the lack/immature features in MySQL such as stored proc or trigger.
>
> Mysql 5 has stored procedures and triggers.
>
> The fact that you have to change between different "storage engines" to
> use transactions properly etc is a little weird (and some of the new
> engines are just bizarre), but that's beside the point.
>
> 90% of open-source software is written to use only mysql (and it's not
> easy to switch to another db) - search freshmeat or sourceforge for
> anything postgresql related.. not much there.
>
> Then, even if you do write something to use postgresql a lot of hosts
> don't support it anyway ('mysql is good enough').. so you're stuck.


Well, I guess the moment all the hoster's have to buy commercial licenses for
providing a database they'll switch to PG in no time - or charge more for the
people who absolutely need mysql.
Maybe it's time to write a sophisticated "mysql to postgresql" automation
tool....

    UC

--
Open Source Solutions 4U, LLC    1618 Kelly St
Phone:  +1 707 568 3056        Santa Rosa, CA 95401
Cell:   +1 650 302 2405        United States
Fax:    +1 707 568 6416

>>Then, even if you do write something to use postgresql a lot of hosts
>>don't support it anyway ('mysql is good enough').. so you're stuck.
>
> Well, I guess the moment all the hoster's have to buy commercial licenses for
> providing a database they'll switch to PG in no time - or charge more for the
> people who absolutely need mysql.
> Maybe it's time to write a sophisticated "mysql to postgresql" automation
> tool....

Converting the database itself is easy (there's a few scripts in contrib
and I've written one myself).

The hard stuff is converting stuff like mysql's "last_insert_id" to a
postgres alternative, fixing queries that aren't standard..

eg mysql doesn't force you to group by all columns being selected - I
can do:

select field1, field2, field3 from table group by field1;

and have it valid in mysql (but of course postgres will tell you it's
not valid and need to add grouping for field2 and field3).

mysql 5 is the first version where you can enforce "not null"
constraints, before that you could do:

create table a(a int, b int not null);
insert into a(a) values('1');

and it would accept it (even though 'b' doesn't have a default value),
so some code could be rather "dodgy" for lack of a better term.


The list goes on about differences (date handling, full text indexing
for example).

On Wednesday 2006-02-15 18:42, Leonard Soetedjo wrote:
> On Wednesday 15 February 2006 01:38, Tom Lane wrote:
> > merlyn@stonehenge.com (Randal L. Schwartz) writes:
> > > Oracle purchases Sleepycat.  From what I understand, BerkeleyDB was the
> > > "other" way that MySQL could have transactions if Oracle decided to
> > > restrict InnoDB tables (after purchasing Innobase last year).
> > >
> > > Does this mean the other shoe has dropped for MySQL AB?
> >
> > The deal's not gone through yet, but it sure does look like they want to
> > put a hammerlock on MySQL ...
>
> Is it possible that Oracle is trying to buy MySQL to kill off other open
> source competitor, e.g. PostgreSQL?  MySQL has a strong number of users and
> therefore it is a good deal for Oracle to buy MySQL.  Then by doing that,
> Oracle will market MySQL as the low-end alternative to their own database
> to give a full solution to the customer.  And this would slow down the take
> up rate for other database competitor.
>
> I just hope not....
>
>
>
> Regards,
>
> Leonard Soetedjo

Given Sleepycat's position in the embedded database market, I think Oracle's
move to acquire the company stands on it's own without the need to assume it
is part of some wider defense against free software.

MySQL's current merchandizable market position can't be that desirable from
Oracle's point of view.  MySQL is best in the lower middle part of the
database market.  You have to sell lots of units and endure much headache to
make money there.  Furthermore you don't need MySQL to do it.  It would be
easy to just hobble and rebrand Oracle to do the same thing.

MySQL's only interesting technology is decoupling the MySQL front end from the
core database engine.  (Which makes me wonder why so many on this list say
PosgreSQL couldn't be coopted.  Wouldn't MySQL just have to change the
PostgreSQL parser?)

The real threat to Oracle from the free software community is that faced by
Microsoft with BSD *nix and Linux: COMMODIFICATION.  Commodification is
already a real threat to Oracle and of the three big commercial databases it
is the least diversified.  For IBM with DB2 database commodification would be
the same mixed blessing as OS commodification.

With 8.1 and autovacuum PostgreSQL finally became partially independent of a
full-time DBA.  This means that in terms of numbers, probably 80% of the big
three database installations could be replaced with PostgreSQL with little or
no loss of functionality (with some proviso for the fact that SQL Server has
a much deeper and more user friendly interface).   The remaining 20% of
installations would obviously be larger and might account for something like
80% of revenue, but the fact remains that the BASIS for database
commodification is well in place.  There is good reason to expect FOSS
database market share to increase considerable over the next 5 to 15 years.

Over the medium term Oracle stands to be challenged hard by database
commodification.  It has two viable strategic options.  First it can try to
buy time for it's database offerings by slowing the rate of commodification.
Second, and more important, it can try to "own" as much of the inevitable
commodification on Oracle's terms as it can.

Note, the gratis deployment of BSD/Linux from a commercial perspective is not
interesting.  Enterprise budgets are never so tight.  The 20% of accounts
that generate 80% of revenues will pay as much or more for Linux as for
Windows if it results in meeting critical business needs.  Google could pay
for Windows or Solaris if it wanted to.

Buying Innobase, and especially Sleepy cat immediately hedges Oracle AGAINST
commodification ESPECIALLY if they maintain BDB's dual license structure.  On
the other hand, Oracle acquires some ability to throttle commodification by
slowing development of dual license software products that it controls.

Furthermore it has put itself in a no-downside position vis-a-vis MySQL and
MySQL's dominant market share of modest web applications.  In the best case
Oracle acquires MySQL. It continues to offer MySQL on GPL terms but manages
the product's future to best insultate the company from near-term FOSS
commodification.  (Commodification defense actually implies *gaining* market
share against FOSS competitors.  Oracle wants to own the dual-license
commodity standard if it can.)  If Oracle can't buy MySQL then it can starve
it for database backends, and MySQL may fold.  In one scenario Oracle still
buys MySQL.  At worst, MySQL is orphaned until a group picks up the GPL code.
Or MySQL may be denied backend engines and soldier on.  In this case,
commodification is still slowed down as MySQL scrambles and its evident role
as the emerging commodity standard (based on market share) is called into
question.

Chris <dmagick@gmail.com> writes:
> eg mysql doesn't force you to group by all columns being selected - I
> can do:
> select field1, field2, field3 from table group by field1;
> and have it valid in mysql (but of course postgres will tell you it's
> not valid and need to add grouping for field2 and field3).

Actually, that *is* legal per SQL99 under certain specified conditions
(eg if field1 is a primary key for table).  We haven't gotten around to
implementing SQL99's relaxed rules for grouping --- we're still
basically doing what SQL92 says.  Now the full SQL99 spec for this is
pretty hairy, but I'd bet lunch that mysql supports only the easier
cases such as group-by-primary-key.  We might be able to cover the same
cases they do without too much sweat ... does anyone want to dig in and
determine exactly which cases they cover?

            regards, tom lane

Tom Lane wrote:
> Chris <dmagick@gmail.com> writes:
>
>>eg mysql doesn't force you to group by all columns being selected - I
>>can do:
>>select field1, field2, field3 from table group by field1;
>>and have it valid in mysql (but of course postgres will tell you it's
>>not valid and need to add grouping for field2 and field3).
>
>
> Actually, that *is* legal per SQL99 under certain specified conditions
> (eg if field1 is a primary key for table).  We haven't gotten around to
> implementing SQL99's relaxed rules for grouping --- we're still
> basically doing what SQL92 says.  Now the full SQL99 spec for this is
> pretty hairy, but I'd bet lunch that mysql supports only the easier
> cases such as group-by-primary-key.  We might be able to cover the same
> cases they do without too much sweat ... does anyone want to dig in and
> determine exactly which cases they cover?

Quick test:

create table a(a int primary key, b int, c varchar(200));
insert into a(a, b, c) values (1,1,'one');
insert into a(a, b, c) values (2,2,'two');
insert into a(a, b, c) values (3,1,'one');
insert into a(a, b, c) values (4,2,'two');

mysql> select a,b,c from a group by a;
+---+------+------+
| a | b    | c    |
+---+------+------+
| 1 |    1 | one  |
| 2 |    2 | two  |
| 3 |    1 | one  |
| 4 |    2 | two  |
+---+------+------+
4 rows in set (0.00 sec)

mysql> select a,b,c from a group by b;
+---+------+------+
| a | b    | c    |
+---+------+------+
| 1 |    1 | one  |
| 2 |    2 | two  |
+---+------+------+
2 rows in set (0.00 sec)

mysql> select a,b,c from a group by c;
+---+------+------+
| a | b    | c    |
+---+------+------+
| 1 |    1 | one  |
| 2 |    2 | two  |
+---+------+------+
2 rows in set (0.00 sec)

As soon as I add an aggregate function like count into the mix it does
the right thing and tells me I need to add a group by:

mysql> select b, count(*) from a;
ERROR 1140: Mixing of GROUP columns (MIN(),MAX(),COUNT()...) with no
GROUP columns is illegal if there is no GROUP BY clause

but doesn't care when I use multiple columns:

mysql> select a, b, c, count(*) from a group by b;
+---+------+------+----------+
| a | b    | c    | count(*) |
+---+------+------+----------+
| 1 |    1 | one  |        2 |
| 2 |    2 | two  |        2 |
+---+------+------+----------+
2 rows in set (0.00 sec)


So it looks like they only check whether one 'group by' is applicable
for a query and that's it.

Chris <dmagick@gmail.com> writes:
> Quick test:

> create table a(a int primary key, b int, c varchar(200));
> insert into a(a, b, c) values (1,1,'one');
> insert into a(a, b, c) values (2,2,'two');
> insert into a(a, b, c) values (3,1,'one');
> insert into a(a, b, c) values (4,2,'two');

> mysql> select a,b,c from a group by b;
> +---+------+------+
> | a | b    | c    |
> +---+------+------+
> | 1 |    1 | one  |
> | 2 |    2 | two  |
> +---+------+------+
> 2 rows in set (0.00 sec)

Egad :-(.  At least the SQL spec has some notion of wanting the answer
to a query to be well-defined ...

            regards, tom lane

Yeah, that's how I remember mysql doing it.  I'm sure postgres
doesn't want anything to do with how they do it.  If I recall it was
kind of convenient sometimes as long as you only select fields that
are unambiguous.

For instance take the query where table "first_table" has primary key
"a":

select first_table.a, first_table.b from first_table inner join
second_table on second_table.a = first_table.a group by first_table.a

Because first_table.id is a primary key tables first_table and
second_table have either a one to one or  a one to many
relationship.  So if you group by first_table.a you know that you can
safely select any other field in that table and it will be unambiguous.

But in postgres you must do:

select first_table.a from first_table inner join second_table on
second_table.a = first_table.a group by first_table.a
or
select first_table.a, first_table.b from first_table inner join
second_table on second_table.a = first_table.a group by
first_table.a, first_table.b

But in mysql you can just do
select first_table.a, first_table.b from first_table inner join
second_table on second_table.a = first_table.a group by first_table.a

The problem is mysql will also allow:
select second_table.x, second_table.y from first_table inner join
second_table on second_table.a = first_table.a group by first_table.a

I just looked up the docs here:

http://dev.mysql.com/doc/refman/5.0/en/group-by-hidden-fields.html

They call it group by with hidden fields and consider it a feature
with the following caveat:

"Do not use this feature if the columns you omit from the GROUP BY
part are not unique in the group! You get unpredictable results."

I could swear that when I looked it up in the docs many years ago
that that it tried to actually explain what value would get picked so
you could actually try to get some use out the undefined cases but I
could be smoking crack.  That was a long time ago.  Some of the
comments are amusing and actually want the docs to clarify when you
might want to use the undefined cases.

Apparently you can also turn that feature off.  Maybe the ability to
turn that "feature" off is one of the new enterprise friendly
features of mysql 5.  :)

This is one of the reasons I am soooo glad I made the switch a long,
long time ago before I became too tied to mysql to easily change.  If
I ever get around to porting over that last ancient barely used
application (yes it uses enums) I can avoid ever having to run mysql
again.

I think it's great if postgres wants to do this intelligently and per
spec but I doubt that mysql has anything to offer here.  They just
handle all of the cases.  Even the ones that shouldn't work.

Rick


On Feb 15, 2006, at 10:39 PM, Tom Lane wrote:

> Chris <dmagick@gmail.com> writes:
>> Quick test:
>
>> create table a(a int primary key, b int, c varchar(200));
>> insert into a(a, b, c) values (1,1,'one');
>> insert into a(a, b, c) values (2,2,'two');
>> insert into a(a, b, c) values (3,1,'one');
>> insert into a(a, b, c) values (4,2,'two');
>
>> mysql> select a,b,c from a group by b;
>> +---+------+------+
>> | a | b    | c    |
>> +---+------+------+
>> | 1 |    1 | one  |
>> | 2 |    2 | two  |
>> +---+------+------+
>> 2 rows in set (0.00 sec)
>
> Egad :-(.  At least the SQL spec has some notion of wanting the answer
> to a query to be well-defined ...
>
>             regards, tom lane
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>        subscribe-nomail command to majordomo@postgresql.org so that
> your
>        message can get through to the mailing list cleanly
>

On Thu, Feb 16, 2006 at 10:39:08AM +0800, Leonard Soetedjo wrote:
> Sidetracking a little, I've got to admit that I'm not very sure of
> the impact of ORM to databases.  Some OO proponents insist on not
> using stored procedure etc. unless there is a compelling reason
> (e.g. Martin Fowler in his book Patterns of Enterprise Application
> Architecture).

I've found "compelling reasons" any time my app isn't one I could
simply download from freshmeat, so I suppose this is true, but only
vacuously.

> So actually a database like MySQL4 would suffice, as much as I hate
> to say it.

Not if you want to get data back out when you put it in, it isn't.

Cheers,
D
--
David Fetter david@fetter.org http://fetter.org/
phone: +1 415 235 3778

Remember to vote!

Vivek Khera wrote:
> http://dev.mysql.com/doc/refman/5.1/en/bdb-restrictions.html
>
> I especially like the third restriction.  How on earth do people live
> with this software?

That's the part where they allow only one NULL value in a unique index,
right? Opinions seem to differ on this matter...

Is it possible to guarantee that an index is unique at all if it
contains NULL values? If I have an index containing [1,2,3,NULL,4,5],
can I say that NULL (it being an "unknown" value) does not equal one of
the other values? Or for that matter, if I'd have multiple NULL values,
can I say they aren't equal? I think not.

The docs say
(http://www.postgresql.org/docs/8.1/static/indexes-unique.html):
"When an index is declared unique, multiple table rows with equal
indexed values will not be allowed. Null values are not considered equal."

But according to:
http://manuals.sybase.com/onlinebooks/group-as/asg1250e/sqlug/@Generic__BookTextView/21064
"The definition of unique constraints in the SQL standards specifies
that the column definition shall not allow null values.", although that
doesn't literally mean NULL values in unique indexes are not allowed...

Here're a few more quotes I stumbled upon while looking for info on this
matter.

from:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_create_64l4.asp

"Microsoft® SQL Server™ checks for duplicate values when the index is
created (if data already exists) and checks each time data is added with
an INSERT or UPDATE statement. If duplicate key values exist, the CREATE
INDEX statement is canceled and an error message giving the first
duplicate is returned. Multiple NULL values are considered duplicates
when UNIQUE index is created."

from:
http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.sqls.doc/sqls02.htm

"IBM Informix Guide to SQL: Syntax
...
A unique index prevents duplicate values in the customer_num column. A
column with a unique index can have, at most, one NULL value."


--
Alban Hertroys
alban@magproductions.nl

magproductions b.v.

T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
    7500 AK Enschede

//Showing your Vision to the World//

Alban Hertroys wrote:
> Vivek Khera wrote:
>> http://dev.mysql.com/doc/refman/5.1/en/bdb-restrictions.html
>>
>> I especially like the third restriction.  How on earth do people live
>> with this software?
>
> That's the part where they allow only one NULL value in a unique index,
> right? Opinions seem to differ on this matter...
>
> Is it possible to guarantee that an index is unique at all if it
> contains NULL values?

No.

 > If I have an index containing [1,2,3,NULL,4,5],
> can I say that NULL (it being an "unknown" value) does not equal one of
> the other values? Or for that matter, if I'd have multiple NULL values,
> can I say they aren't equal? I think not.

Exactly so.

> The docs say
> (http://www.postgresql.org/docs/8.1/static/indexes-unique.html):
> "When an index is declared unique, multiple table rows with equal
> indexed values will not be allowed. Null values are not considered equal."
>
> But according to:
> http://manuals.sybase.com/onlinebooks/group-as/asg1250e/sqlug/@Generic__BookTextView/21064
>
> "The definition of unique constraints in the SQL standards specifies
> that the column definition shall not allow null values.", although that
> doesn't literally mean NULL values in unique indexes are not allowed...

It's a tricky question. The only really clean solution is to say that a
UNIQUE constraint requires NOT NULL on all its columns. This is what
happens when you define a primary key of course.

I suppose you *could* say that with a unique constraint over (a,b,c)
then if (1,2,null) is already in the table (1,2,<anything>) is then
forbidden since you can't guarantee it won't conflict. In effect saying
"can I prove this is different from existing values", which of course is
  "no" if you're comparing against nulls.

If you're only allowing one null value, you're saying NULL=NULL which of
course is not true. I can see *why* dbms builders choose to do that, but
I don't think it's right.

--
   Richard Huxton
   Archonet Ltd

On Thu, 2006-02-16 at 06:27, Alban Hertroys wrote:
> Vivek Khera wrote:
> > http://dev.mysql.com/doc/refman/5.1/en/bdb-restrictions.html
> >
> > I especially like the third restriction.  How on earth do people live
> > with this software?
>
> That's the part where they allow only one NULL value in a unique index,
> right? Opinions seem to differ on this matter...
>

ISTM the part that is bad on this is not that whether you allow multiple
nulls in a unique index (as some dbs do) or that you allow a single null
in a unique index (as other dbs do), either behvior can be argued for.
The thing that get's me is that as a mysql developer you really can't be
sure of the behavior you are going to get unless you can enforce a
specific table handler which therefore requires that you require a
specific storage engine for that installation. ISTM this is asking for a
lot of knowledge of mysql internals for the average front end
developer.


Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

On Feb 16, 2006, at 6:27 AM, Alban Hertroys wrote:

> Vivek Khera wrote:
>> http://dev.mysql.com/doc/refman/5.1/en/bdb-restrictions.html
>> I especially like the third restriction.  How on earth do people
>> live  with this software?
>
> That's the part where they allow only one NULL value in a unique
> index, right? Opinions seem to differ on this matter...

Ok, fair enough... but you still get different behavior depending on
your table type in mysql, which is just idiotic...  At least with
every other system, you get what you get all the time, not just some
of the time.

Alban Hertroys <alban@magproductions.nl> writes:
> But according to:
> http://manuals.sybase.com/onlinebooks/group-as/asg1250e/sqlug/@Generic__BookTextView/21064
> "The definition of unique constraints in the SQL standards specifies
> that the column definition shall not allow null values.", although that
> doesn't literally mean NULL values in unique indexes are not allowed...

Sybase is wrong here, or at least pretty misleading.  SQL92 does allow
minimal SQL implementations to impose such a restriction:

         2) The following restrictions apply for Entry SQL in addition to
            any Intermediate SQL restrictions:

            a) If PRIMARY KEY or UNIQUE is specified, then the <column defi-
              nition> for each column whose <column name> is in the <unique
              column list> shall specify NOT NULL.

But if you don't enforce that, the spec clearly requires you to accept
rows that are duplicate but contain nulls.  11.7 <unique constraint
definition> sayeth:

         3) Case:

            a) If the <unique specification> specifies PRIMARY KEY, then let
              SC be the <search condition>:

                 UNIQUE ( SELECT UCL FROM TN )
                 AND
                 ( UCL ) IS NOT NULL

            b) Otherwise, let SC be the <search condition>:

                 UNIQUE ( SELECT UCL FROM TN )

     [ UCL = unique column list, TN = table name --- tgl ]

    ...

         2) The unique constraint is not satisfied if and only if

              EXISTS ( SELECT * FROM TN WHERE NOT ( SC ) )

            is true.

and the UNIQUE predicate (a thing we don't currently implement btw)
is defined in 8.9:

         <unique predicate> ::= UNIQUE <table subquery>

         1) Let T be the result of the <table subquery>.

         2) If there are no two rows in T such that the value of each column
            in one row is non-null and is equal to the value of the cor-
            responding column in the other row according to Subclause 8.2,
            "<comparison predicate>", then the result of the <unique predi-
            cate> is true; otherwise, the result of the <unique predicate>
            is false.

It says "each column" has to be non-null --- so a row containing any
nulls is simply not able to cause a violation of a UNIQUE constraint.

Your other quotes show that a number of implementations get this wrong :-(.
Date and Darwen read it the same way we do, though (see pages 248 and
254 in A Guide to the SQL Standard, 4th edition), so I have confidence
that our reading is correct.

            regards, tom lane

Vivek Khera wrote:
>
> On Feb 16, 2006, at 6:27 AM, Alban Hertroys wrote:
>
>> Vivek Khera wrote:
>>
>>> http://dev.mysql.com/doc/refman/5.1/en/bdb-restrictions.html
>>> I especially like the third restriction.  How on earth do people
>>> live  with this software?
>>
>>
>> That's the part where they allow only one NULL value in a unique
>> index, right? Opinions seem to differ on this matter...
>
>
> Ok, fair enough... but you still get different behavior depending on
> your table type in mysql, which is just idiotic...  At least with  every
> other system, you get what you get all the time, not just some  of the
> time.

I wasn't trying to justify mysql's behaviour in this respect (Me? No way!)

It merely got me wondering what the correct implementation of a UNIQUE
constraint regarding NULL values would be. Verifying my own ideas
against the PostgreSQL docs and various results from Google turned up
some interesting differences in points of view. Hence the quotes :P

I still think one shouldn't allow NULL values in unique constraints
unless it's the _only_ value (any value is unique if there are no other
values to compare with, after all), but I can't compare myself to
C.Date, Darwen or Tom Lane... I'm not a database deity :P

I suspect they have some pretty good reasons to treat NULL values in a
UNIQUE constraint as different even from other NULL values. It sure
makes me curious though ;)

Regards,

--
Alban Hertroys
alban@magproductions.nl

magproductions b.v.

T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
    7500 AK Enschede

//Showing your Vision to the World//

On Wed, 2006-02-15 at 21:12, Chris wrote:
> >>Then, even if you do write something to use postgresql a lot of hosts
> >>don't support it anyway ('mysql is good enough').. so you're stuck.
> >
> > Well, I guess the moment all the hoster's have to buy commercial licenses for
> > providing a database they'll switch to PG in no time - or charge more for the
> > people who absolutely need mysql.
> > Maybe it's time to write a sophisticated "mysql to postgresql" automation
> > tool....
>
> Converting the database itself is easy (there's a few scripts in contrib
> and I've written one myself).
>
> The hard stuff is converting stuff like mysql's "last_insert_id" to a
> postgres alternative, fixing queries that aren't standard..
>
> eg mysql doesn't force you to group by all columns being selected - I
> can do:

The funny thing is that by fixing these things, which MySQL seems to be
doing one at a time, they make PostgreSQL more and more attractive at
least as a co supported database for most applications.  If you've got
to fix 19 queries to make MySQL 5.1 work, and only one more query to
make PostgreSQL work, you might was well.

Alban Hertroys <alban@magproductions.nl> writes:
> I suspect they have some pretty good reasons to treat NULL values in a
> UNIQUE constraint as different even from other NULL values. It sure
> makes me curious though ;)

Date & Darwen make it pretty clear that they think this sucks, and in
fact that they think SQL's definition of nulls sucks in general.  But
that's how the spec is written.

            regards, tom lane

Tom Lane <tgl@sss.pgh.pa.us> writes:

> Egad :-(.  At least the SQL spec has some notion of wanting the answer
> to a query to be well-defined ...

Yeah, the MySQL interpretation of this is basically as a shorter form of
Postgres's DISTINCT ON syntax. There's something to be said for MySQL's which
doesn't introduce an orthogonal syntax to GROUP BY with basically equivalent
meaning, but there's a lot to be said for having a syntax that you can't write
by accident as well.

--
greg

>
> I still think one shouldn't allow NULL values in unique constraints
> unless it's the _only_ value (any value is unique if there are no other
> values to compare with, after all), but I can't compare myself to
> C.Date, Darwen or Tom Lane... I'm not a database deity :P

You can not declare a unique value on nothing... thus the reasoning :)

>
> I suspect they have some pretty good reasons to treat NULL values in a
> UNIQUE constraint as different even from other NULL values. It sure
> makes me curious though ;)
>
> Regards,
>


--
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

Leonard Soetedjo wrote:
> On Wednesday 15 February 2006 01:38, Tom Lane wrote:
> > merlyn@stonehenge.com (Randal L. Schwartz) writes:
> > > Oracle purchases Sleepycat.  From what I understand, BerkeleyDB was the
> > > "other" way that MySQL could have transactions if Oracle decided to
> > > restrict InnoDB tables (after purchasing Innobase last year).
> > >
> > > Does this mean the other shoe has dropped for MySQL AB?
> >
> > The deal's not gone through yet, but it sure does look like they want to
> > put a hammerlock on MySQL ...
>
> Is it possible that Oracle is trying to buy MySQL to kill off other open
> source competitor, e.g. PostgreSQL?  MySQL has a strong number of users and
> therefore it is a good deal for Oracle to buy MySQL.  Then by doing that,
> Oracle will market MySQL as the low-end alternative to their own database to
> give a full solution to the customer.  And this would slow down the take up
> rate for other database competitor.

MySQL already has major funding.  I don't see how it could get worse for
us if Oracle bought them.

--
  Bruce Momjian   http://candle.pha.pa.us
  SRA OSS, Inc.   http://www.sraoss.com

  + If your life is a hard drive, Christ can be your backup. +

On Fri, 24 Feb 2006, Bruce Momjian wrote:

> Leonard Soetedjo wrote:
>> On Wednesday 15 February 2006 01:38, Tom Lane wrote:
>>> merlyn@stonehenge.com (Randal L. Schwartz) writes:
>>>> Oracle purchases Sleepycat.  From what I understand, BerkeleyDB was the
>>>> "other" way that MySQL could have transactions if Oracle decided to
>>>> restrict InnoDB tables (after purchasing Innobase last year).
>>>>
>>>> Does this mean the other shoe has dropped for MySQL AB?
>>>
>>> The deal's not gone through yet, but it sure does look like they want to
>>> put a hammerlock on MySQL ...
>>
>> Is it possible that Oracle is trying to buy MySQL to kill off other open
>> source competitor, e.g. PostgreSQL?  MySQL has a strong number of users and
>> therefore it is a good deal for Oracle to buy MySQL.  Then by doing that,
>> Oracle will market MySQL as the low-end alternative to their own database to
>> give a full solution to the customer.  And this would slow down the take up
>> rate for other database competitor.
>
> MySQL already has major funding.  I don't see how it could get worse for
> us if Oracle bought them.

I think that Leonards point here is that if Oracle were to acquire them
and market MySQL as 'the low-end alternative', that they have a huge
marketing budget that they could bring to bear on this ... one that I
imagine makes MySQL's look like pocket change ...

Greatbridge had "major funding", and succeeded in burning it off in, what,
12 months?

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

On Fri, Feb 24, 2006 at 10:52:53 -0400,
  "Marc G. Fournier" <scrappy@postgresql.org> wrote:
> On Fri, 24 Feb 2006, Bruce Momjian wrote:
>
> Greatbridge had "major funding", and succeeded in burning it off in, what,
> 12 months?

It's been a long time, but I thought they still had a significant amount
of money left when Greatbridge was shut down.

Marc G. Fournier wrote:
> On Fri, 24 Feb 2006, Bruce Momjian wrote:
>
>> MySQL already has major funding.  I don't see how it could get worse for
>> us if Oracle bought them.
>
> I think that Leonards point here is that if Oracle were to acquire them
> and market MySQL as 'the low-end alternative', that they have a huge
> marketing budget that they could bring to bear on this ... one that I
> imagine makes MySQL's look like pocket change ...
>
> Greatbridge had "major funding", and succeeded in burning it off in,
> what, 12 months?

Umm, I think MySQL has executed a little better than the late Great Bridge.  I should know.

I think Bruce's point was that any Oracle-MySQL combination would just be more of the same - highly visible low-end
database,not really challenging Oracle 10, single-company-directed, not really that open a development community. 

Frankly, I think that would be pretty good news for PostgreSQL.  It would just underscore the strengths of the PG
community. Will be interesting to see if Oracle really does buy JBoss or Zend, and whether those communities fork in
someway as has been widely forecast.  I think the point that "it can't happen to PostgreSQL" is pretty solid. 

That's not to say marketing's not extremely important for PostgreSQL.  We're still the underdog in that fight, and
wouldbe more so if Oracle bought MySQL.   

Bruno Wolff III <bruno@wolff.to> writes:
>   "Marc G. Fournier" <scrappy@postgresql.org> wrote:
>> Greatbridge had "major funding", and succeeded in burning it off in, what,
>> 12 months?

> It's been a long time, but I thought they still had a significant amount
> of money left when Greatbridge was shut down.

Oh, certainly.  Lack of money was not the problem --- GB was performing
according to plan, which was to become profitable within three years,
but the board of directors got cold feet.

            regards, tom lane

Without going into the particulars, let's just say the total amount spent was less than publicly announced figures, and
theparent (sole investor) shut it down before coming close to those figures. 


Bruno Wolff III wrote:
> On Fri, Feb 24, 2006 at 10:52:53 -0400,
>   "Marc G. Fournier" <scrappy@postgresql.org> wrote:
>> On Fri, 24 Feb 2006, Bruce Momjian wrote:
>>
>> Greatbridge had "major funding", and succeeded in burning it off in, what,
>> 12 months?
>
> It's been a long time, but I thought they still had a significant amount
> of money left when Greatbridge was shut down.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match
>
>
>

Bruno Wolff III wrote:
> On Fri, Feb 24, 2006 at 10:52:53 -0400,
>   "Marc G. Fournier" <scrappy@postgresql.org> wrote:
> > On Fri, 24 Feb 2006, Bruce Momjian wrote:
> >
> > Greatbridge had "major funding", and succeeded in burning it off in, what,
> > 12 months?
>
> It's been a long time, but I thought they still had a significant amount
> of money left when Greatbridge was shut down.

Right, they closed the company before the full promised amount was
spent, but they did spend millions, for sure.


--
  Bruce Momjian   http://candle.pha.pa.us
  SRA OSS, Inc.   http://www.sraoss.com

  + If your life is a hard drive, Christ can be your backup. +