Skip site navigation (1)
Skip section navigation (2)
Peripheral Links
Re: NULLs in unique indexes; Was: Oracle purchases Sleepycat
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(at)stonehenge(dot)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(at)stonehenge(dot)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
Tom Lane wrote: > merlyn(at)stonehenge(dot)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(at)noao(dot)edu The gods that smiled on your birth are now laughing out loud.
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(at)hub(dot)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(at)hub(dot)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(at)postgresql(dot)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
On Tue, 14 Feb 2006, Stephen Frost wrote: > * Marc G. Fournier (scrappy(at)postgresql(dot)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(at)hub(dot)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(at)sidhe(dot)org have teddy bears and even
teddy bears get drunk
Stephen Frost <sfrost(at)snowman(dot)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
* Marc G. Fournier (scrappy(at)postgresql(dot)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
merlyn(at)stonehenge(dot)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.
On Tue, 2006-02-14 at 12:54, Marc G. Fournier wrote: > On Tue, 14 Feb 2006, Stephen Frost wrote: > > > * Marc G. Fournier (scrappy(at)postgresql(dot)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.
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(at)snowman(dot)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(at)varlena(dot)com
On 2/14/06, Dan Sugalski <dan(at)sidhe(dot)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(at)sidhe(dot)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(at)sidhe(dot)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(at)khera(dot)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(at)sss(dot)pgh(dot)pa(dot)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(at)stonehenge(dot)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(at)sss(dot)pgh(dot)pa(dot)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(at)stonehenge(dot)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(at)alpinenetworking(dot)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(at)aw(dot)sgi(dot)com (Dean Edmonds)
On Wednesday 15 February 2006 01:38, Tom Lane wrote: > merlyn(at)stonehenge(dot)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(at)stonehenge(dot)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(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664
> On Wednesday 15 February 2006 01:38, Tom Lane wrote: >> merlyn(at)stonehenge(dot)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(at)hotmail(dot)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(at)stonehenge(dot)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(at)gmail(dot)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(at)gmail(dot)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(at)gmail(dot)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(at)gmail(dot)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(at)postgresql(dot)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(at)fetter(dot)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(at)magproductions(dot)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(at)magproductions(dot)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(at)magproductions(dot)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(at)magproductions(dot)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(at)sss(dot)pgh(dot)pa(dot)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(at)stonehenge(dot)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(at)stonehenge(dot)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(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664
On Fri, Feb 24, 2006 at 10:52:53 -0400, "Marc G. Fournier" <scrappy(at)postgresql(dot)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 some way 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 would be more so if Oracle bought MySQL.
Bruno Wolff III <bruno(at)wolff(dot)to> writes: > "Marc G. Fournier" <scrappy(at)postgresql(dot)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 the parent (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(at)postgresql(dot)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(at)postgresql(dot)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. +