Thread: Oracle buys Innobase
http://lnk.nu/prnewswire.com/4dv.pl -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
Jim C. Nasby wrote: > http://lnk.nu/prnewswire.com/4dv.pl Amazing. You have to love the totally unrelated license mention Oracle added to the press release: InnoDB is not a standalone database product: it is distributed as a part of the MySQL database. InnoDB's contractual relationship with MySQL comes up for renewal next year. Oracle fully expects to negotiate an extension of that relationship. Read $$$. This is the logical way Oracle would attack a competitor (buy up a key piece of their technology). Oracle looked for MySQL's easiest weakness to exploit, and found it. It isn't even vaguely cloaked, because InnoDB doesn't even have a db product, it is just licensed by MySQL. This certainly puts a dent in the MySQL 5.0 press buzz, which I suppose was part of the timing. Do open source users want licensed technology from a company owned by Oracle? I doubt it. My guess is that the InnoDB license will now be used as FUD against MySQL perpetually. This might also be related to the article by the MySQL CEO saying they are not competing with Oracle: http://www.cbronline.com/article_news.asp?guid=9231B8BD-3788-4DB2-B85F-707E75857B58 This might be a sort of detente saying MySQL will not move into Oracle accounts. Certainly the MySQL CEO must have known this was coming, so his comments now appear in a different light. What is our vulnerability? Oracle offering big-money jobs to PostgreSQL developers. I think that is our only weakness, unless they buy Marc (Marc, are you for sale? :-) ) and own the domains and trademark. Ultimately, MySQL should drop InnoDB. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce, > What is our vulnerability? Oracle offering big-money jobs to PostgreSQL > developers. I think that is our only weakness, unless they buy Marc > (Marc, are you for sale? :-):-) ) and own the domains and trademark. Well, that *is* a serious concern. That's why Marc and I are working on making sure these things are legally protected. -- --Josh Josh Berkus Aglio Database Solutions San Francisco
> Ultimately, MySQL should drop InnoDB.
This will happen eventually, there is no doubt, Sun seems like its
going to eventually integrate PostgreSQL into Solaris as a pkg most
likely:
http://www.computerworld.com.au/index.php/id;116679278;fp;16;fpid;0
Hopefully that should make PostgreSQL shine even more. Maybe we
may also see some @sun.com contributers, okay that maybe wishful thinking.
Cheers,
Aly.
--
Aly S.P Dharshi
aly.dharshi@telus.net
"A good speech is like a good dress
that's short enough to be interesting
and long enough to cover the subject"
Aly S.P Dharshi wrote: > > > Ultimately, MySQL should drop InnoDB. > > This will happen eventually, there is no doubt, Sun seems like its > going to eventually integrate PostgreSQL into Solaris as a pkg most > likely: > > http://www.computerworld.com.au/index.php/id;116679278;fp;16;fpid;0 > > Hopefully that should make PostgreSQL shine even more. Maybe we > may also see some @sun.com contributers, okay that maybe wishful thinking. I have seen @sun.com posters already, so it has started. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Ultimately, MySQL should drop InnoDB.
Given that MyISAM is still their first love, I don't think that outcome
is preposterous at all. If Oracle tries to squeeze too hard, that's
probably exactly what they'll do. It'll put a bit of a dent in their
claims to having transaction support, but I think their bread-and-butter
applications are still mostly MyISAM.
regards, tom lane
On Fri, 7 Oct 2005, Bruce Momjian wrote: > What is our vulnerability? Oracle offering big-money jobs to PostgreSQL > developers. I think that is our only weakness, unless they buy Marc > (Marc, are you for sale? :-) ) and own the domains and trademark. I'm not for sale, else I would have sold a *long* time ago ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Bruce Momjian <pgman@candle.pha.pa.us> schrieb: > Ultimately, MySQL should drop InnoDB. http://forums.mysql.com/read.php?3,48400,48400#msg-48400 InnoDB is GPL. But, i'm also confused. My guess: a fork in the future. Regards, Andreas -- Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect. (Linus Torvalds) Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889°
(This is via Exchange Web client, I apologize in advance for any htmlitudeiness of this message)
What it comes down to is this. MySQL is dual licensed. You can use the GPL version, or the commercial version. In order to sell the commercially licensed version, MySQL must have the rights to all the code in their base. So, in order for MySQL to sell a commercail version of MySQL with innodb support, they have to pay innobase a bit to include it, or rip it out.
So, now Oracle can just raise the price high enough that either the commercial version of MySQL has to go up to cover the price, or they are forced to remove it. If MySQL makes the choice to remove it from the commercial version, they will likely take it out of the GPL version as well, since they likely don't want the commercially licensed version to be the red headed step child of the GPL version, since their business plan relies on convincing people they need the commercial license as much as possible.
-----Original Message-----
From: pgsql-general-owner@postgresql.org on behalf of Andreas Kretschmer
Sent: Sat 10/8/2005 3:34 AM
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Oracle buys Innobase
Bruce Momjian <pgman@candle.pha.pa.us> schrieb:
> Ultimately, MySQL should drop InnoDB.
http://forums.mysql.com/read.php?3,48400,48400#msg-48400
InnoDB is GPL. But, i'm also confused.
My guess: a fork in the future.
Regards, Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889°
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
On 10/8/2005 4:34 AM, Andreas Kretschmer wrote: > Bruce Momjian <pgman@candle.pha.pa.us> schrieb: >> Ultimately, MySQL should drop InnoDB. > > http://forums.mysql.com/read.php?3,48400,48400#msg-48400 > > InnoDB is GPL. But, i'm also confused. > > My guess: a fork in the future. This whole GPL forking thing is still the same as it was before. One can only take the last version, released under GPL, and build a GPL-only project based on it. Oracle bought the copyright of InnoDB with the company. So if anything goes wrong during their upcoming relicensing talk, MySQL can of course fork off a GPL version of InnoDB, but that fork cannot be included in their commercial version of MySQL. What value would that fork have for them then? Using a pure GPL fork of InnoDB is in conflict with their own licensing scheme and I don't think MySQL is in the position to say bye to dual licensing. To have a really good position when talking to Oracle, MySQL will need to brush up on the BDB support, and that pretty quick. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
Jan Wieck wrote: > On 10/8/2005 4:34 AM, Andreas Kretschmer wrote: > > > Bruce Momjian <pgman@candle.pha.pa.us> schrieb: > >> Ultimately, MySQL should drop InnoDB. > > > > http://forums.mysql.com/read.php?3,48400,48400#msg-48400 > > > > InnoDB is GPL. But, i'm also confused. > > > > My guess: a fork in the future. > > This whole GPL forking thing is still the same as it was before. One can > only take the last version, released under GPL, and build a GPL-only > project based on it. > > Oracle bought the copyright of InnoDB with the company. So if anything > goes wrong during their upcoming relicensing talk, MySQL can of course > fork off a GPL version of InnoDB, but that fork cannot be included in > their commercial version of MySQL. What value would that fork have for > them then? Using a pure GPL fork of InnoDB is in conflict with their own > licensing scheme and I don't think MySQL is in the position to say bye > to dual licensing. > > To have a really good position when talking to Oracle, MySQL will need > to brush up on the BDB support, and that pretty quick. What about the patents InnoDB might hold? It would be easier to enforce a patent based on the fact that they are using code actually developed by the patent holder. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
On 10/8/2005 12:13 PM, Bruce Momjian wrote: > Jan Wieck wrote: >> To have a really good position when talking to Oracle, MySQL will need >> to brush up on the BDB support, and that pretty quick. > > What about the patents InnoDB might hold? It would be easier to enforce > a patent based on the fact that they are using code actually developed > by the patent holder. That too. What strikes me a little odd is how brief the responses from the MySQL side are. Marten Mickos welcomes them, does some 2 sentence handwaving about licensing and the glorious freedom of open source, and then the rest of the statement is the usual blah blah about MySQL that you find in every other press release. It almost seems as if MySQL wasn't exactly prepared for this deal to come through - or worse, that they are surprised about it. Although I can't believe they wouldn't have known about it in advance. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
Hi That is terrific news being a former employee of MySQL - Oracle buys Innobase. I was never a fan of MySQL, personally but when Marten Mikos and the rest of the business wonks joined the Company I knew then it was time to get out. I met the author of Innobase once at the first MySQL employees meeting. I was asked what for an opinion on Heikki Tuuri. I came straight to point and told Monty and David (Axmark) that Heikki Tuuri can not be trusted. It seems I was right. Mr Tuuri has no interest in supporting the OS commumity. His only interest is in making money. My gut feeling now is that eventually Oracle will buy off Innobase lock stock and barell Then Innonbase will get consigned to File 13. I now see MySQL heading for a long slow death; it couldn't happen to a nicer group of people :) Thank God for PostreSQL At 18:42 08/10/2005, Jan Wieck wrote: >On 10/8/2005 12:13 PM, Bruce Momjian wrote: > >>Jan Wieck wrote: >>>To have a really good position when talking to Oracle, MySQL will need >>>to brush up on the BDB support, and that pretty quick. >>What about the patents InnoDB might hold? It would be easier to enforce >>a patent based on the fact that they are using code actually developed >>by the patent holder. > >That too. > >What strikes me a little odd is how brief the responses from the MySQL >side are. Marten Mickos welcomes them, does some 2 sentence handwaving >about licensing and the glorious freedom of open source, and then the rest >of the statement is the usual blah blah about MySQL that you find in every >other press release. > >It almost seems as if MySQL wasn't exactly prepared for this deal to come >through - or worse, that they are surprised about it. Although I can't >believe they wouldn't have known about it in advance. > > >Jan > >-- >#======================================================================# ># It's easier to get forgiveness for being wrong than for being right. # ># Let's break this rule - forgive me. # >#================================================== JanWieck@Yahoo.com # > >---------------------------(end of broadcast)--------------------------- >TIP 5: don't forget to increase your free space map settings > --- Regards John Dean, co-author of Rekall, the only alternative to MS Access
Jan Wieck wrote: > To have a really good position when talking to Oracle, MySQL will need > to brush up on the BDB support, and that pretty quick. Maybe Oracle will buy Sleepycat too, and foreclose that option ;-)
On Sat, 8 Oct 2005, Jan Wieck wrote: > On 10/8/2005 12:13 PM, Bruce Momjian wrote: > >> Jan Wieck wrote: >>> To have a really good position when talking to Oracle, MySQL will need to >>> brush up on the BDB support, and that pretty quick. >> >> What about the patents InnoDB might hold? It would be easier to enforce >> a patent based on the fact that they are using code actually developed >> by the patent holder. > > That too. > > What strikes me a little odd is how brief the responses from the MySQL side > are. Marten Mickos welcomes them, does some 2 sentence handwaving about > licensing and the glorious freedom of open source, and then the rest of the > statement is the usual blah blah about MySQL that you find in every other > press release. > > It almost seems as if MySQL wasn't exactly prepared for this deal to come > through - or worse, that they are surprised about it. Although I can't > believe they wouldn't have known about it in advance. Or, they knew about it and have some sort of contigency plan already in place for when the license does expire ... ? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Bruce, Aly, > > Hopefully that should make PostgreSQL shine even more. Maybe we > > may also see some @sun.com contributers, okay that maybe wishful > > thinking. > > I have seen @sun.com posters already, so it has started. Actually, the Sun folks have been contributing indirectly for a while, and are working on getting Solaris binary packaging organized. They're just not big on joining mailing lists, something we need to educate them on. -- Josh Berkus Aglio Database Solutions San Francisco
On Sat, Oct 08, 2005 at 10:31:30AM -0500, Scott Marlowe wrote:
> What it comes down to is this. MySQL is dual licensed. You can use
> the GPL version, or the commercial version. In order to sell the
> commercially licensed version, MySQL must have the rights to all the
> code in their base. So, in order for MySQL to sell a commercail
> version of MySQL with innodb support, they have to pay innobase a
> bit to include it, or rip it out.
I don't understand. If both MySQL and Innodb are GPL licensed,
commercial or not should make no difference, and they can add all the
GPL changes they want o the last Innodb GPL release.
What am I missing?
--
... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
Felix Finch: scarecrow repairman & rocket surgeon / felix@crowfix.com
GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o
El Sáb 08 Oct 2005 18:11, felix@crowfix.com escribió:
> On Sat, Oct 08, 2005 at 10:31:30AM -0500, Scott Marlowe wrote:
>
> > What it comes down to is this. MySQL is dual licensed. You can use
> > the GPL version, or the commercial version. In order to sell the
> > commercially licensed version, MySQL must have the rights to all the
> > code in their base. So, in order for MySQL to sell a commercail
> > version of MySQL with innodb support, they have to pay innobase a
> > bit to include it, or rip it out.
>
> I don't understand. If both MySQL and Innodb are GPL licensed,
> commercial or not should make no difference, and they can add all the
> GPL changes they want o the last Innodb GPL release.
>
> What am I missing?
They can't enforce a commercial licence over a GPL aplication.
--
select 'mmarques' || '@' || 'unl.edu.ar' AS email;
---------------------------------------------------------
Martín Marqués | Programador, DBA
Centro de Telemática | Administrador
Universidad Nacional
del Litoral
---------------------------------------------------------
On Oct 8, 2005, at 5:11 PM, felix@crowfix.com wrote: > I don't understand. If both MySQL and Innodb are GPL licensed, > commercial or not should make no difference, and they can add all the > GPL changes they want o the last Innodb GPL release. MySQL owns their code so they can release it with whatever license they want. Since they don't own the Innodb code they can't include it in a commercially licensed product.
On Sat, Oct 08, 2005 at 02:11:54PM -0700, felix@crowfix.com wrote: > On Sat, Oct 08, 2005 at 10:31:30AM -0500, Scott Marlowe wrote: > > > What it comes down to is this. MySQL is dual licensed. You can use > > the GPL version, or the commercial version. In order to sell the > > commercially licensed version, MySQL must have the rights to all the > > code in their base. So, in order for MySQL to sell a commercail > > version of MySQL with innodb support, they have to pay innobase a > > bit to include it, or rip it out. > > I don't understand. If both MySQL and Innodb are GPL licensed, > commercial or not should make no difference, and they can add all the > GPL changes they want o the last Innodb GPL release. > > What am I missing? MySQL isn't GPL, it's a modified GPL. But the real issue is that they can't use the GPL licensed InnoDB in their commercial product. They have to obtain a commercial license for that. And I suspect Oracle's going to want more than they can afford for that license. Though AFAIK there wouldn't be anything illegal about someone with a commercial license of MySQL using the GPL'd version of InnoDB... but of course if they did that they'd have GPL'd software again, so no reason to pay for the commercial license of MySQL. This is the first time I can think of where software being GPL'd might actually hurt the open-source community. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
felix@crowfix.com writes:
> I don't understand. If both MySQL and Innodb are GPL licensed,
> commercial or not should make no difference, and they can add all the
> GPL changes they want o the last Innodb GPL release.
> What am I missing?
MySQL AB wants to make money by selling non-GPL versions of MySQL.
They can certainly dual-license MySQL itself, because they own it
outright, but they could not ship InnoDB as part of a non-GPL-license
MySQL sale without InnoDB's (and now Oracle's) permission. So they've
got a financial problem with this.
regards, tom lane
On 10/8/05, Mitch Pirtle <mitch.pirtle@gmail.com> wrote: > > This basically means that InnoDB table support must come out of the > commercial MySQL. For that matter, I'm not sure they can release MySQL under a commercial license while incorporating 3rd party GPL works, without the express permission of the copyright holders for those included works. Whatever deal they used to have just got changed, that's for sure. -- Mitch
On 10/8/05, felix@crowfix.com <felix@crowfix.com> wrote: > > I don't understand. If both MySQL and Innodb are GPL licensed, > commercial or not should make no difference, and they can add all the > GPL changes they want o the last Innodb GPL release. They can only do the GPL stuff in the GPL-licensed MySQL; and they cannot incorporate someone else's GPL works in a proprietary (non-GPL) commercial release. This basically means that InnoDB table support must come out of the commercial MySQL. -- Mitch
felix@crowfix.com writes: > On Sat, Oct 08, 2005 at 10:31:30AM -0500, Scott Marlowe wrote: > >> What it comes down to is this. MySQL is dual licensed. You can use >> the GPL version, or the commercial version. In order to sell the >> commercially licensed version, MySQL must have the rights to all the >> code in their base. So, in order for MySQL to sell a commercail >> version of MySQL with innodb support, they have to pay innobase a >> bit to include it, or rip it out. > > I don't understand. If both MySQL and Innodb are GPL licensed, > commercial or not should make no difference, and they can add all > the GPL changes they want o the last Innodb GPL release. Yes, that is correct, MySQL can still distribute a GPLed version of MySQL that includes InnoDB no matter what Oracle might do. However, MySQL AB's current business strategy relies heavily on being able to sell MySQL under a commercial license. If Oracle changes the deal that MySQL AB has with InnoBase then it will be impossible for MySQL AB to sell a version of MySQL with support for InnoDB tables under a commercial license. All of MySQL's fancy new features revolve around the far more capable InnoDB tables. Without that table type MySQL reverts right back to the toy it was at version 3.2. MyISAM tables lack ACID transactions, row level locking, hot backup ability, and basically everything else you would want out of a database. Oracle now has MySQL AB over a barrel. I imagine that when it comes time to renegotiate the InnoBase license next year that the balance of power in that relationship will shift dramatically. > What am I missing? What you are missing is that MySQL AB the company and MySQL the database are two different things. MySQL the database will still be distributable under the GPL, but even MySQL AB isn't going to be able to distribute MySQL with the InnoDB table type under anything but the GPL if Oracle yanks MySQL AB's license. Of course, it's entirely possible that Oracle isn't planning to torpedo MySQL and that the InnoBase/MySQL AB relationship will remain unchanged, but this news has got to make MySQL AB's commercial customers nervous. Jason
On Sat, Oct 08, 2005 at 02:11:54PM -0700, felix@crowfix.com wrote:
>
> What am I missing?
[ many answers ]
Ahhh ... I did not realize they were selling a commercial version with
a dual license. I had thought they were selling support contracts.
I confess I find this weird too. I can't see why someone wouild want
to distribute their own private label version of MySQL, unless they
were making significant changes, and then I can't see why anyone would
want to buy such a version. But I have met many people, not just
corporate types, who think $0 = worthless, and $$ not as good as
$$$$$$, even for the exact same piece of gear.
--
... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
Felix Finch: scarecrow repairman & rocket surgeon / felix@crowfix.com
GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o
felix@crowfix.com writes: > On Sat, Oct 08, 2005 at 10:31:30AM -0500, Scott Marlowe wrote: > >> What it comes down to is this. MySQL is dual licensed. You can use >> the GPL version, or the commercial version. In order to sell the >> commercially licensed version, MySQL must have the rights to all the >> code in their base. So, in order for MySQL to sell a commercail >> version of MySQL with innodb support, they have to pay innobase a >> bit to include it, or rip it out. > > I don't understand. If both MySQL and Innodb are GPL licensed, > commercial or not should make no difference, and they can add all the > GPL changes they want o the last Innodb GPL release. > > What am I missing? If they do not hold a fairly unrestricted license to *resell* InnoDB, then MySQL AB would be unable to sell "traditional proprietary commercial licenses" to the combination of MySQL and InnoDB, which is the way that they actually _make money_. Based on the comments in Oracle's press release, it appears that MySQL AB *does* have some form of contract with InnoDB Oy Inc to resell InnoDB, but that contract expires some time next year. If the contract is not renewed, then MySQL AB would only be permitted to link MySQL (tm) to InnoDB under the conditions of the GPL, which would mean that MySQL AB could only distribute a MySQL(tm)/InnoDB(tm) combination under the conditions of the GPL. This would essentially *destroy* their revenue model, which is predicated on the notion of selling people a "traditional proprietary license" to MySQL+InnoDB on the basis that they should be fearful of GPL-licensed software as it always forces you to release your code "for free." (There's some truth to this, but possibly not as much as MySQL AB would have you believe.) -- let name="cbbrowne" and tld="cbbrowne.com" in String.concat "@" [name;tld];; http://www.ntlug.org/~cbbrowne/oses.html Black holes are where God divided by zero.
On Oct 8, 2005, at 6:40 PM, Mitch Pirtle wrote: > On 10/8/05, Mitch Pirtle <mitch.pirtle@gmail.com> wrote: > >> This basically means that InnoDB table support must come out of the >> commercial MySQL. > > For that matter, I'm not sure they can release MySQL under a > commercial license while incorporating 3rd party GPL works, without > the express permission of the copyright holders for those included > works. > > Whatever deal they used to have just got changed, that's for sure. > > -- Mitch All of which seems to beg the question: why did not MySQL buy Innobase themselves? As far as I've read, the terms of the transaction were not disclosed. I guess it's possible that MySQL didn't have the financial reach to pull off the deal. -- Thomas F. O'Connell Co-Founder, Information Architect Sitening, LLC Strategic Open Source: Open Your i™ http://www.sitening.com/ 110 30th Avenue North, Suite 6 Nashville, TN 37203-6320 615-469-5150 615-469-5151 (fax)
> All of which seems to beg the question: why did not MySQL buy > Innobase themselves? As far as I've read, the terms of the > transaction were not disclosed. I guess it's possible that MySQL > didn't have the financial reach to pull off the deal. Maybe they didn't think it was necessary. In any event, they're far from the first (or last) company to underestmate the aggressive business tactics of Oracle, which isn't doing this out of the goodness of their hearts. My guess is that the people at Oracle looked at the number of ISPs who offer their customers MySQL database support and saw a market to tap. Oracle's tried to tap the 'small database server' market before, badly. If the folks at MySQL AB are smart, they may be considering selling out to Oracle too, before they get left out in the cold. Are there any lessons to be learned from this with regards to PostgreSQL? -- Mike Nolan
On Sat, 8 Oct 2005, Mike Nolan wrote: >> All of which seems to beg the question: why did not MySQL buy >> Innobase themselves? As far as I've read, the terms of the >> transaction were not disclosed. I guess it's possible that MySQL >> didn't have the financial reach to pull off the deal. > > Maybe they didn't think it was necessary. In any event, they're far from > the first (or last) company to underestmate the aggressive business tactics > of Oracle, which isn't doing this out of the goodness of their hearts. > > My guess is that the people at Oracle looked at the number of ISPs who > offer their customers MySQL database support and saw a market to tap. > Oracle's tried to tap the 'small database server' market before, badly. > > If the folks at MySQL AB are smart, they may be considering selling out > to Oracle too, before they get left out in the cold. > > Are there any lessons to be learned from this with regards to PostgreSQL? IMHO, not really ... nobody *owes* the PostgreSQL code base, and we aren't reliant on any third parties for key parts of the server, so Oracle would essentially have to go after the commercial vendors themselves, and even going after them wouldn't buy them *that* much, I wouldn't think ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
felix@crowfix.com writes: > On Sat, Oct 08, 2005 at 02:11:54PM -0700, felix@crowfix.com wrote: >> >> What am I missing? > > [ many answers ] > > Ahhh ... I did not realize they were selling a commercial version with > a dual license. I had thought they were selling support contracts. > > I confess I find this weird too. I can't see why someone wouild > want to distribute their own private label version of MySQL, unless > they were making significant changes, and then I can't see why > anyone would want to buy such a version. But I have met many > people, not just corporate types, who think $0 = worthless, and $$ > not as good as $$$$$$, even for the exact same piece of gear. That's part of the reason that MySQL AB went around to all of the MySQL database adaptor guys and hired them and changed the license on them to the GPL. There were lots of people that wanted to include a database with their software and LGPLed drivers let them do that even if the database itself was under the GPL. Now with GPLed drivers for MySQL if you distribute your application you either need a commercial license of MySQL or you need to GPL your application. MySQL made a pretty penny convincing application writers that they needed a commercial license of MySQL if their application wasn't distributed under the GPL. It wasn't about support contracts per se, but rather about being able to include an inexpensive database with a commercial application. In some ways that actually shouldn't be a problem since the drivers are the part get gets "linked" with the commercial application, and they are still owned by MySQL AB. However, it's going to look funny if MySQL AB has to offer MySQL itself under the GPL in order to include InnoDB tables and they simply sell the database drivers under a commercial license. Any way you look at it, there are interesting times ahead for MySQL AB. Personally I think that it is just Karma. After years of disinformation they are getting what they deserve. Jason
On Saturday 08 October 2005 17:35, Chris Browne wrote:
> felix@crowfix.com writes:
> > On Sat, Oct 08, 2005 at 10:31:30AM -0500, Scott Marlowe wrote:
> >> What it comes down to is this. MySQL is dual licensed. You can use
> >> the GPL version, or the commercial version. In order to sell the
> >> commercially licensed version, MySQL must have the rights to all the
> >> code in their base. So, in order for MySQL to sell a commercail
> >> version of MySQL with innodb support, they have to pay innobase a
> >> bit to include it, or rip it out.
> >
> > I don't understand. If both MySQL and Innodb are GPL licensed,
> > commercial or not should make no difference, and they can add all the
> > GPL changes they want o the last Innodb GPL release.
> >
> > What am I missing?
>
> If they do not hold a fairly unrestricted license to *resell* InnoDB,
> then MySQL AB would be unable to sell "traditional proprietary
> commercial licenses" to the combination of MySQL and InnoDB, which is
> the way that they actually _make money_.
>
> Based on the comments in Oracle's press release, it appears that MySQL
> AB *does* have some form of contract with InnoDB Oy Inc to resell
> InnoDB, but that contract expires some time next year.
>
> If the contract is not renewed, then MySQL AB would only be permitted
> to link MySQL (tm) to InnoDB under the conditions of the GPL, which
> would mean that MySQL AB could only distribute a MySQL(tm)/InnoDB(tm)
> combination under the conditions of the GPL.
>
> This would essentially *destroy* their revenue model, which is
> predicated on the notion of selling people a "traditional proprietary
> license" to MySQL+InnoDB on the basis that they should be fearful of
> GPL-licensed software as it always forces you to release your code
> "for free." (There's some truth to this, but possibly not as much as
> MySQL AB would have you believe.)
Didn't MySQL AB acquire SAPdb (which was Adabas D before)? AFAIK (and you're
welcome to correct me since I might very well be wrong) SAPdb supports
transactions and foreign keys. If that's the case MySQL AB might be in a
position to offer the bells and whistles without InnoDB support if they work
out the deficiencies of SAPdb.
--
UC
--
Open Source Solutions 4U, LLC 2570 Fleetwood Drive
Phone: +1 650 872 2425 San Bruno, CA 94066
Cell: +1 650 302 2405 United States
Fax: +1 650 872 2417
On Oct 8, 2005, at 10:34 PM, Marc G. Fournier wrote: >> Are there any lessons to be learned from this with regards to >> PostgreSQL? Like Marc said, doesn't seem to be a worry to the Postgres community . . . Unless this is all really an Oracle ploy to grab the competition to the their real future fear . . . PostgreSQL X : ) Seriously though, whereas MySQL's ease of use was a draw to the burgeoning web designers-turned-PHP codies, a lot of heavy DB users considered and still consider Postgres the open-source alternative to Oracle. When I was new to DB newbie, I followed that crowd (like the OpenACS folks) from Oracle to Postgres. While this deal doesn't change the quality of MySQL at all yet, it could affect the evangelizing efforts of the community. It can't help, I wouldn't think, unless Oracle just smothers them out, which is possible, though not probable, since the two database's customers are so different and there is money to be made by keeping the DB alive. A community would always remain to take up the torch, but the Postgres community builds Postgres, while the MySQL community has a different dynamic entirely.
tfo@sitening.com ("Thomas F. O'Connell") writes:
> On Oct 8, 2005, at 6:40 PM, Mitch Pirtle wrote:
>
>> On 10/8/05, Mitch Pirtle <mitch.pirtle@gmail.com> wrote:
>>
>>> This basically means that InnoDB table support must come out of the
>>> commercial MySQL.
>>
>> For that matter, I'm not sure they can release MySQL under a
>> commercial license while incorporating 3rd party GPL works, without
>> the express permission of the copyright holders for those included
>> works.
>>
>> Whatever deal they used to have just got changed, that's for sure.
>
> All of which seems to beg the question: why did not MySQL buy
> Innobase themselves? As far as I've read, the terms of the
> transaction were not disclosed. I guess it's possible that MySQL
> didn't have the financial reach to pull off the deal.
It is interesting that MySQL AB did not put some option into their
original deal with InnoDB that would make it easy for them to do a
buyout of the code in case "something naughty might happen."
If I were making my product dependent on [X], I'd want to be careful
to assure myself that I could continue to have access to [X];
according to what I see in the Oracle statement, it doesn't appear as
though there was anything more specific than a contract ending some
time next year.
Mind you, it is not public what goes away in 2006. It is possible
that MySQL AB has a more-or-less perpetual license to use InnoDB as it
stands today, in which case it would be entirely possible that they
would fork the code base, and maintain the "MySQL version of InnoDB"
themselves. Continuing access to the present version would represent
a reasonable "option" for MySQL AB...
In any case, there are doubtless a few lawyers in Europe that are
pretty busy this weekend :-).
--
output = ("cbbrowne" "@" "acm.org")
http://www.ntlug.org/~cbbrowne/linuxxian.html
I just removed the instructions in MC:COMMON;LINS > which specify that
it should be installed on AI. We'll certainly miss that machine, and
probably spend the rest of our lives fixing programs that mention it.
felix@crowfix.com wrote: > I confess I find this weird too. I can't see why someone wouild want > to distribute their own private label version of MySQL, unless they > were making significant changes, and then I can't see why anyone > would want to buy such a version. The suits do this for peace of mind. They are very nervous about entrusting corporate data to open source databases with no support. Why else do you think companies are willing to pay Oracle $300,000 per CPU? At 2 am if something gets corrupted, they can call Oracle and attempt to get it fixed. -- Guy Rouillier
On Oct 8, 2005, at 11:25 PM, Uwe C. Schroeder wrote: > Didn't MySQL AB acquire SAPdb (which was Adabas D before)? AFAIK (and > you're > welcome to correct me since I might very well be wrong) SAPdb supports > transactions and foreign keys. If that's the case MySQL AB might be > in a > position to offer the bells and whistles without InnoDB support if > they work > out the deficiencies of SAPdb. Or maybe SQLite? I was looking for some other options and saw this page. It look like the author mistakenly calls PostgreSQL GPL'd. http://linas.org/linux/db.html
uwe@oss4u.com ("Uwe C. Schroeder") writes:
> Didn't MySQL AB acquire SAPdb (which was Adabas D before)? AFAIK
> (and you're welcome to correct me since I might very well be wrong)
> SAPdb supports transactions and foreign keys. If that's the case
> MySQL AB might be in a position to offer the bells and whistles
> without InnoDB support if they work out the deficiencies of SAPdb.
They did that indeed, or at least they acquired a license to SAP-DB.
(I think SAP AG retains license as well; this is akin to the way USL
sold SysV licenses to many vendors...)
The problems with Max-DB are twofold:
1. It isn't at all compatible with the "legacy" MySQL applications.
It is essentially a database system with a similar "flavour" to
Oracle version 7. That's not much similar to MySQL 3.x or 4.x.
2. The code base was pretty old, pretty creaky, and has a *really*
heavy learning curve.
It was pretty famous as being *really* difficult to build; throw
together such things as:
- It uses a custom set of build tools that were created for a
mainframe environment and sorta hacked into Python
- Naming conventions for files, variables, and functions combine
pseudo-German with an affinity for 8 character names that are
anything but mnemonic. (Think: "Germans developing on MVS.")
- I seem to recall there being a Pascal translator to transform
some of the code into C++...
Doing substantial revisions to it seems unlikely. Doing terribly
much more than trying to keep it able to compile on a few
platforms of interest seems unlikely.
When they announced at OSCON that MySQL 5.0 would have all of the
features essential to support SAP R/3, that fit the best theories
available as to why they took on "MaxDB", namely to figure out the
minimal set of additions needed to get MySQL to be able to host R/3.
If that be the case, then Oracle just took about the minimal action
necessary to take the wind out of their sails :-).
--
"cbbrowne","@","cbbrowne.com"
http://cbbrowne.com/info/linuxdistributions.html
Atheism is a non-prophet organization.
Chris Browne <cbbrowne@acm.org> writes:
> When they announced at OSCON that MySQL 5.0 would have all of the
> features essential to support SAP R/3, that fit the best theories
> available as to why they took on "MaxDB", namely to figure out the
> minimal set of additions needed to get MySQL to be able to host R/3.
[ Trying to drag this thread back to something Postgres-related ;-) ]
Does anyone have a clear idea how far *we* are from being able to
support SAP?
regards, tom lane
On Saturday 08 October 2005 21:07, Chris Browne wrote:
> uwe@oss4u.com ("Uwe C. Schroeder") writes:
> > Didn't MySQL AB acquire SAPdb (which was Adabas D before)? AFAIK
> > (and you're welcome to correct me since I might very well be wrong)
> > SAPdb supports transactions and foreign keys. If that's the case
> > MySQL AB might be in a position to offer the bells and whistles
> > without InnoDB support if they work out the deficiencies of SAPdb.
>
> They did that indeed, or at least they acquired a license to SAP-DB.
> (I think SAP AG retains license as well; this is akin to the way USL
> sold SysV licenses to many vendors...)
>
> The problems with Max-DB are twofold:
>
> 1. It isn't at all compatible with the "legacy" MySQL applications.
>
> It is essentially a database system with a similar "flavour" to
> Oracle version 7. That's not much similar to MySQL 3.x or 4.x.
>
> 2. The code base was pretty old, pretty creaky, and has a *really*
> heavy learning curve.
>
> It was pretty famous as being *really* difficult to build; throw
> together such things as:
> - It uses a custom set of build tools that were created for a
> mainframe environment and sorta hacked into Python
> - Naming conventions for files, variables, and functions combine
> pseudo-German with an affinity for 8 character names that are
> anything but mnemonic. (Think: "Germans developing on MVS.")
> - I seem to recall there being a Pascal translator to transform
> some of the code into C++...
WOW - careful now. I'm german - but then, there's a reason why I immigrated to
the US :-)
>
> Doing substantial revisions to it seems unlikely. Doing terribly
> much more than trying to keep it able to compile on a few
> platforms of interest seems unlikely.
>
> When they announced at OSCON that MySQL 5.0 would have all of the
> features essential to support SAP R/3, that fit the best theories
> available as to why they took on "MaxDB", namely to figure out the
> minimal set of additions needed to get MySQL to be able to host R/3.
>
> If that be the case, then Oracle just took about the minimal action
> necessary to take the wind out of their sails :-).
SAPdb (aka Adabas D) is something I worked with quite a while ago. And you're
right, the naming schemes and restrictions, as well as severe
incompatibilities with the SQL standard where one of my major reasons to drop
that database in favor of Informix (at that time) and PostgreSQL later on.
It was kind of tough to generate explanatory table names with those kind of
limitations. Nonetheless back then (maybe around 1993) Adabas D was a quite
powerful and considerably cheap alternative to anything serious at the market
- and it was easy to sell to customers (back in germany) just because this
was THE database powering SAP R/3.
But you may be right - considering what the codebase of SAPdb must look like
it's probably unlikely MySQL AB can make any considerable improvements in the
time available.
UC
--
Open Source Solutions 4U, LLC 2570 Fleetwood Drive
Phone: +1 650 872 2425 San Bruno, CA 94066
Cell: +1 650 302 2405 United States
Fax: +1 650 872 2417
On Sat, Oct 08, 2005 at 05:01:50PM -0500, Jim C. Nasby wrote: > Though AFAIK there wouldn't be anything illegal about someone with a > commercial license of MySQL using the GPL'd version of InnoDB... but of > course if they did that they'd have GPL'd software again, so no reason > to pay for the commercial license of MySQL. > > This is the first time I can think of where software being GPL'd might > actually hurt the open-source community. Well now, that kind of depends on what you define as "hurt". If you were only ever interested in the GPL version, none of this makes a whit of difference. If all you wanted was that your code was shared and that people who benefitted shared also, then the GPL serves the purpose. Without the GPL possibly neither InnoDB or MySQL would have been open-source in the first place. (Maybe, maybe not. I'm not going to argue this point). OTOH, if your goal is to "share the wealth" and let everyone get good code for whatever purpose they want, then they would have chosen BSD licence. This is what PostgreSQL does. The political goals of the GPL are hardly secret. Some people might consider this an example of what happens if you rely on proprietary software models. At least we still have the code *now* (under the GPL). Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
Attachment
On Sun, Oct 09, 2005 at 03:16:22PM +0200, Martijn van Oosterhout wrote: > On Sat, Oct 08, 2005 at 05:01:50PM -0500, Jim C. Nasby wrote: > > Though AFAIK there wouldn't be anything illegal about someone with a > > commercial license of MySQL using the GPL'd version of InnoDB... but of > > course if they did that they'd have GPL'd software again, so no reason > > to pay for the commercial license of MySQL. > > > > This is the first time I can think of where software being GPL'd might > > actually hurt the open-source community. > > Well now, that kind of depends on what you define as "hurt". If you > were only ever interested in the GPL version, none of this makes a whit > of difference. > > If all you wanted was that your code was shared and that people who > benefitted shared also, then the GPL serves the purpose. Without the > GPL possibly neither InnoDB or MySQL would have been open-source in the > first place. (Maybe, maybe not. I'm not going to argue this point). > > OTOH, if your goal is to "share the wealth" and let everyone get good > code for whatever purpose they want, then they would have chosen BSD > licence. This is what PostgreSQL does. > > The political goals of the GPL are hardly secret. Some people might > consider this an example of what happens if you rely on proprietary > software models. At least we still have the code *now* (under the GPL). Well, consider that MySQL would probably still be trying to figure out what a subquery was if it didn't have commercial backing from it's parent company. Hurting that parent company is going to impact the code. Of course, this works both ways. It used to be that Linux was definately behind FreeBSD from a technology standpoint. After companies like IBM have poured millions into it that's no longer the case. It's certainly possible that these companies adopted Linux over FreeBSD because it was GPL'd. But at least for the database market, the GPL license seems to be a downside for MySQL. Many commercial users would rather use a non-GPL'd database, and pay companies for support. Those companies can then give back to the community. So whereas MySQL only has support from MySQL AB, PostgreSQL has support from more than a half-dozen companies (some with very big pockets). And since most all the code in PostgreSQL is BSD licensed, I don't think it would be possible for Oracle to 'pull the rug out from under us' as they appear to have just done with MySQL. Of course this is nothing but handwaving at this point. It'll be interesting to see where things are at 6 months from now. Maybe Oracle's going to use InnoDB as the basis for version 11! ;P -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
uwe@oss4u.com ("Uwe C. Schroeder") writes:
> On Saturday 08 October 2005 21:07, Chris Browne wrote:
>> 2. The code base was pretty old, pretty creaky, and has a *really*
>> heavy learning curve.
>>
>> It was pretty famous as being *really* difficult to build; throw
>> together such things as:
>> - It uses a custom set of build tools that were created for a
>> mainframe environment and sorta hacked into Python
>> - Naming conventions for files, variables, and functions combine
>> pseudo-German with an affinity for 8 character names that are
>> anything but mnemonic. (Think: "Germans developing on MVS.")
>> - I seem to recall there being a Pascal translator to transform
>> some of the code into C++...
>
> WOW - careful now. I'm german - but then, there's a reason why I
> immigrated to the US :-)
I'm 1/4 German, and a couple brothers married German girls, so I'm not
trying to be mean, by any stretch.
The bad Procrustean part is the "8 character mainframe" aspect, as it
takes things that might have been mnemonic, at least to those knowing
German, and distills things down in size so as to lose even that.
It truly *was* Germans developing on MVS (or TSO or OS/360 or such)...
>> Doing substantial revisions to it seems unlikely. Doing terribly
>> much more than trying to keep it able to compile on a few
>> platforms of interest seems unlikely.
>>
>> When they announced at OSCON that MySQL 5.0 would have all of the
>> features essential to support SAP R/3, that fit the best theories
>> available as to why they took on "MaxDB", namely to figure out the
>> minimal set of additions needed to get MySQL to be able to host R/3.
>>
>> If that be the case, then Oracle just took about the minimal action
>> necessary to take the wind out of their sails :-).
>
> SAPdb (aka Adabas D) is something I worked with quite a while ago. And you're
> right, the naming schemes and restrictions, as well as severe
> incompatibilities with the SQL standard where one of my major reasons to drop
> that database in favor of Informix (at that time) and PostgreSQL later on.
> It was kind of tough to generate explanatory table names with those kind of
> limitations. Nonetheless back then (maybe around 1993) Adabas D was a quite
> powerful and considerably cheap alternative to anything serious at the market
> - and it was easy to sell to customers (back in germany) just because this
> was THE database powering SAP R/3.
And SAP R/3 has its own "8 character mainframe limits," often
involving somewhat Germanic things, abbreviated :-).
> But you may be right - considering what the codebase of SAPdb must
> look like it's probably unlikely MySQL AB can make any considerable
> improvements in the time available.
When Slashdot sorts of people propose "Oh, that can just be another
storage engine!", well, I'll believe it if I see someone implement the
refactoring.
In one of the recent discussions, someone proposed the thought of
MySQL AB adopting the PostgreSQL storage engine as Yet Another One Of
Their Engines. Hands up, anyone that thinks that's likely tomorrow
:-).
What would seem interesting to me would be the idea of building a
PostgreSQL front end for "Tutorial D" as an alternative to SQL. I
don't imagine that will be happening tomorrow, either. :-)
--
(reverse (concatenate 'string "gro.gultn" "@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/oses.html
Rules of the Evil Overlord #200. "During times of peace, my Legions of
Terror will not be permitted to lie around drinking mead and eating
roast boar. Instead they will be required to obey my dietician and my
aerobics instructor." <http://www.eviloverlord.com/>
Chris Browne wrote:
> uwe@oss4u.com ("Uwe C. Schroeder") writes:
>
>>On Saturday 08 October 2005 21:07, Chris Browne wrote:
>>
>>> 2. The code base was pretty old, pretty creaky, and has a *really*
>>> heavy learning curve.
>>>
>>> It was pretty famous as being *really* difficult to build; throw
>>> together such things as:
>>> - It uses a custom set of build tools that were created for a
>>> mainframe environment and sorta hacked into Python
>>> - Naming conventions for files, variables, and functions combine
>>> pseudo-German with an affinity for 8 character names that are
>>> anything but mnemonic. (Think: "Germans developing on MVS.")
>>> - I seem to recall there being a Pascal translator to transform
>>> some of the code into C++...
>>
>>WOW - careful now. I'm german - but then, there's a reason why I
>>immigrated to the US :-)
>
>
> I'm 1/4 German, and a couple brothers married German girls, so I'm not
> trying to be mean, by any stretch.
>
> The bad Procrustean part is the "8 character mainframe" aspect, as it
> takes things that might have been mnemonic, at least to those knowing
> German, and distills things down in size so as to lose even that.
>
> It truly *was* Germans developing on MVS (or TSO or OS/360 or such)...
>
>
>>> Doing substantial revisions to it seems unlikely. Doing terribly
>>> much more than trying to keep it able to compile on a few
>>> platforms of interest seems unlikely.
>>>
>>>When they announced at OSCON that MySQL 5.0 would have all of the
>>>features essential to support SAP R/3, that fit the best theories
>>>available as to why they took on "MaxDB", namely to figure out the
>>>minimal set of additions needed to get MySQL to be able to host R/3.
>>>
>>>If that be the case, then Oracle just took about the minimal action
>>>necessary to take the wind out of their sails :-).
>>
>>SAPdb (aka Adabas D) is something I worked with quite a while ago. And you're
>>right, the naming schemes and restrictions, as well as severe
>>incompatibilities with the SQL standard where one of my major reasons to drop
>>that database in favor of Informix (at that time) and PostgreSQL later on.
>>It was kind of tough to generate explanatory table names with those kind of
>>limitations. Nonetheless back then (maybe around 1993) Adabas D was a quite
>>powerful and considerably cheap alternative to anything serious at the market
>>- and it was easy to sell to customers (back in germany) just because this
>>was THE database powering SAP R/3.
>
>
> And SAP R/3 has its own "8 character mainframe limits," often
> involving somewhat Germanic things, abbreviated :-).
>
>
>>But you may be right - considering what the codebase of SAPdb must
>>look like it's probably unlikely MySQL AB can make any considerable
>>improvements in the time available.
>
>
> When Slashdot sorts of people propose "Oh, that can just be another
> storage engine!", well, I'll believe it if I see someone implement the
> refactoring.
>
> In one of the recent discussions, someone proposed the thought of
> MySQL AB adopting the PostgreSQL storage engine as Yet Another One Of
> Their Engines. Hands up, anyone that thinks that's likely tomorrow
> :-).
>
> What would seem interesting to me would be the idea of building a
> PostgreSQL front end for "Tutorial D" as an alternative to SQL. I
> don't imagine that will be happening tomorrow, either. :-)
But much more interesting to consider, indeed.
Look what somebody suggested! ----------------------------------------------- If the worst happens and Oracle tries to squash InnoDB, there may already be such an alternative out there. I wonder what it would take to add (and optimize) Postgres storage engine support to MySQL? I don't know exactly how current versions of MySQL and Postgres maesure up performance-wise, but PgSQL seems to have made steady progress on performance improvements. Maybe this is a crazy idea, I don't know how technically or legally feasible it is, but I really like the idea of the two open-source communities uniting to battle Oracle. http://jeremy.zawodny.com/blog/archives/005490.html#comment-21233 __________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs
Stupid question, but what does MySQL bring to the equation? Why not just use PostgreSQL in the first place? On Sun, 9 Oct 2005, CSN wrote: > Look what somebody suggested! > > ----------------------------------------------- > > If the worst happens and Oracle tries to squash > InnoDB, there may already be such an alternative out > there. > > I wonder what it would take to add (and optimize) > Postgres storage engine support to MySQL? I don't know > exactly how current versions of MySQL and Postgres > maesure up performance-wise, but PgSQL seems to have > made steady progress on performance improvements. > > Maybe this is a crazy idea, I don't know how > technically or legally feasible it is, but I really > like the idea of the two open-source communities > uniting to battle Oracle. > > http://jeremy.zawodny.com/blog/archives/005490.html#comment-21233 > > > > __________________________________ > Start your day with Yahoo! - Make it your home page! > http://www.yahoo.com/r/hs > > ---------------------------(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 > ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Yep, those were two of my very first questions too. ;) CSN --- "Marc G. Fournier" <scrappy@postgresql.org> wrote: > > Stupid question, but what does MySQL bring to the > equation? Why not just > use PostgreSQL in the first place? > > On Sun, 9 Oct 2005, CSN wrote: > > > Look what somebody suggested! > > > > ----------------------------------------------- > > > > If the worst happens and Oracle tries to squash > > InnoDB, there may already be such an alternative > out > > there. > > > > I wonder what it would take to add (and optimize) > > Postgres storage engine support to MySQL? I don't > know > > exactly how current versions of MySQL and Postgres > > maesure up performance-wise, but PgSQL seems to > have > > made steady progress on performance improvements. > > > > Maybe this is a crazy idea, I don't know how > > technically or legally feasible it is, but I > really > > like the idea of the two open-source communities > > uniting to battle Oracle. > > > > > http://jeremy.zawodny.com/blog/archives/005490.html#comment-21233 > > > > > > > > __________________________________ > > Start your day with Yahoo! - Make it your home > page! > > http://www.yahoo.com/r/hs > > > > ---------------------------(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 > > > > ---- > Marc G. Fournier Hub.Org Networking > Services (http://www.hub.org) > Email: scrappy@hub.org Yahoo!: yscrappy > ICQ: 7615664 > __________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/
Marc G. Fournier wrote: > Stupid question, but what does MySQL bring to the equation? MySQL brings to the table an impressive AI interface that knows what you really meant to do and thus does away with those pesky error messages. After all, who wants to be told that 0000-00-00 is not a date, or that you tried to insert a value of 70000 into a SMALLINT column? Why not > just use PostgreSQL in the first place? > > On Sun, 9 Oct 2005, CSN wrote: > >> Look what somebody suggested! >> >> ----------------------------------------------- >> >> If the worst happens and Oracle tries to squash >> InnoDB, there may already be such an alternative out >> there. >> >> I wonder what it would take to add (and optimize) >> Postgres storage engine support to MySQL? I don't know >> exactly how current versions of MySQL and Postgres >> maesure up performance-wise, but PgSQL seems to have >> made steady progress on performance improvements. >> >> Maybe this is a crazy idea, I don't know how >> technically or legally feasible it is, but I really >> like the idea of the two open-source communities >> uniting to battle Oracle. >> >> http://jeremy.zawodny.com/blog/archives/005490.html#comment-21233 >> >> >> >> __________________________________ >> Start your day with Yahoo! - Make it your home page! >> http://www.yahoo.com/r/hs >> >> ---------------------------(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 >> > > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 > > ---------------------------(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 10/9/05, Rick Morris <rick@brainscraps.com> wrote: > Marc G. Fournier wrote: > > Stupid question, but what does MySQL bring to the equation? > > MySQL brings to the table an impressive AI interface that knows what you > really meant to do and thus does away with those pesky error messages. > > After all, who wants to be told that 0000-00-00 is not a date, or that > you tried to insert a value of 70000 into a SMALLINT column? > LOL, this is the single greatest reason I stopped using mysql for my own stuff. I like the user management aspect better, in that each user only sees their own databases, but that's a small annoyance (a little "psql -l | grep <user>" largely solves that) Whoever decided that silently truncating values and other similar things was a good idea should be shot. Never ever ever ever ever silently do anything that changes data you stupid bitch of a database. Either accept the data as is or reject it and throw an error and make me do the change myself so at least I can control it.
On Sun, 9 Oct 2005, CSN wrote: > > Maybe this is a crazy idea, I don't know how > technically or legally feasible it is, but I really > like the idea of the two open-source communities > uniting to battle Oracle. > Two? I haven't used Firebird, but have heard lots of positive comments from users. Firebird/Postgres/MySQL together maybe? Or with all the embedded SQLlite users out there, perhaps all four.... :-) (& yes, I know there are still others) Cheers Brent Wood
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Stupid question, but what does MySQL bring to the equation? Why > not just use PostgreSQL in the first place? A good question. I think one answer is the MySQL name. Many open-source advocates seem enamored of MySQL, but you can never pin them down about exactly what it is they love so much about it. Maybe we can rebrand PG as "MiSQL" or something. :) The other answer may be the license: plugging PG into the MySQL system (which is about as technically feasible trying to breed a porpoise and an elephant) keeps MySQL GPL, which is another reason many people like it. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200510101028 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iD8DBQFDSnrqvJuQZxSWSsgRAj7lAJ96I0TGpeOTFSkR91J8FLLIjU2ekgCgsM7C DfI6bse1MVYUVrW9uGl69hM= =ose4 -----END PGP SIGNATURE-----
Greg Sabino Mullane wrote: > > The other answer may be the license: plugging PG into the MySQL system > (which is about as technically feasible trying to breed a porpoise > and an elephant) keeps MySQL GPL, which is another reason many people > like it. > The fact that PostgreSQL is NOT released under GPL is the reason that people like me are here - MySQL's license drove us away from them. Their change of the driver licensing prevents us from shipping new drivers with our applications. GPL is a poison pill when it comes to groups like us that are trying to develop standards (and shared code bases) that can be used by both opensource and corporate types alike. So keep up the good work! Dan -- **************************** Daniel Armbrust Biomedical Informatics Mayo Clinic Rochester daniel.armbrust(at)mayo.edu http://informatics.mayo.edu/
Brent Wood wrote: >Two? I haven't used Firebird, but have heard lots of positive comments >from users. Firebird/Postgres/MySQL together maybe? Or with all the >embedded SQLlite users out there, perhaps all four.... :-) i can't think of a single good reason why anyone in the PostgreSQL community would put any time or energy into helping save MySQL AB's bacon. one of the downsides of FUD campaigns is that people remember these things. PostgreSQL is BSD licensed, they can take it if they want and try and do something with it. good luck trying and all that. richard
On Mon, 10 Oct 2005 09:53:17 -0500 Dan Armbrust <daniel.armbrust.list@gmail.com> wrote: > The fact that PostgreSQL is NOT released under GPL is the reason that > people like me are here - MySQL's license drove us away from them. > Their change of the driver licensing prevents us from shipping new > drivers with our applications. > > GPL is a poison pill when it comes to groups like us that are trying > to develop standards (and shared code bases) that can be used by both > opensource and corporate types alike. > > So keep up the good work! > > Dan Preach it brother! Michael
pgsql-general-owner@postgresql.org wrote on 10/09/2005 08:16:22 AM: > > > > This is the first time I can think of where software being GPL'd might > > actually hurt the open-source community. The MySQL license has been modified so that it is, IMHO, not compatible with the GPL. The basic tenet of the GPL is that I can freely copy and distribute, I just have to give back my contributions. MySQL cannot be freely copied and distributed if you are going to make money. MySQL built a business model based on this modification, not on GPL. Had they left the GPL alone and used a consulting business model, they would not be in this mess. The business model, the GPLing of the drivers, and the FUD show a commercial operation parading as a FOSS advocate. I find the discussion of FOSS RDBMS developers uniting against Oracle strange. What are you going to hit them with? Your massive marketing budgets? The only weapon available is the quality of the products, and PostgreSQL is already wielding that weapon mightily. What is Oracle after? Small DB technology? They already have rdb. Firebird, back in the Groton Database Corporation days, was built to be compatible with rdb. Marrying those technologies through modification of existing gateways makes more technological sense than InnoDB. Oracle is trying for market share, as they always do, but it appears ill conceived. MySQL is for people who can't or won't tune and manage a DBMS. Oracle products are just not going to fit. Both on price and complexity. If they kill MySQL, they are just going to increase other true FOSS RDBMS projects' market share. Power to them. Cheers, Rick
Marc G. Fournier wrote: >Stupid question, but what does MySQL bring to the equation? Why not just >use PostgreSQL in the first place? really. to my mind, the best thing the PostgreSQL community can do for the MySQL community is provide simple, easy to use migration tools and documentation. cheers, richard
On 10/7/05, Jim C. Nasby <jnasby@pervasive.com> wrote:
http://lnk.nu/prnewswire.com/4dv.pl
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
First thing that comes to my mind is that Oracle is setting the stage to buy them out.
On 10/10/05, Greg Sabino Mullane <greg@turnstep.com> wrote: > > A good question. I think one answer is the MySQL name. Many open-source > advocates seem enamored of MySQL, but you can never pin them down about > exactly what it is they love so much about it. Maybe we can rebrand > PG as "MiSQL" or something. :) Don't you mean "OurSQL"? - Mitch, with an evil grin
From: http://www.filmsite.org/whof4.html Valiant: Come on. Nobody's gonna drive this lousy freeway when they can take the Red Car for a nickel. Doom: Oh, they'll drive. They'll have to. You see, I bought the Red Car so I could dismantle it. I don't think Oracle has any interest in InnoDB other than to pull the rug out from under the commercial version of MySQL. Ranks right up there with MS's gutting of STAK and Sun's claim of language ownership for Java. IMO-YMMV. ________________________________________ From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org] On Behalf Of snacktime Sent: Monday, October 10, 2005 10:14 AM To: pgsql-general@postgresql.org Subject: Re: [GENERAL] Oracle buys Innobase On 10/7/05, Jim C. Nasby <jnasby@pervasive.com> wrote: http://lnk.nu/prnewswire.com/4dv.pl -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster First thing that comes to my mind is that Oracle is setting the stage to buy them out.
Stupid question here, but how susceptible is Oracle to "monopolistic practices", similar to what M$ is going through with the DoJ in the US? This seems to be *very* close to the line, if it isn't over it ... no? On Mon, 10 Oct 2005, Dann Corbit wrote: > From: > http://www.filmsite.org/whof4.html > > Valiant: Come on. Nobody's gonna drive this lousy freeway when they can take the Red Car for a nickel. > Doom: Oh, they'll drive. They'll have to. You see, I bought the Red Car so I could dismantle it. > > I don't think Oracle has any interest in InnoDB other than to pull the rug out from under the commercial version of MySQL. Ranks right up there with MS's gutting of STAK and Sun's claim of language ownership for Java. > IMO-YMMV. > ________________________________________ > From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org] On Behalf Of snacktime > Sent: Monday, October 10, 2005 10:14 AM > To: pgsql-general@postgresql.org > Subject: Re: [GENERAL] Oracle buys Innobase > > > On 10/7/05, Jim C. Nasby <jnasby@pervasive.com> wrote: > http://lnk.nu/prnewswire.com/4dv.pl > -- > Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com > Pervasive Software http://pervasive.com work: 512-231-6117 > vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster > > First thing that comes to my mind is that Oracle is setting the stage to buy them out. > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq > ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
I think it kind of depends on how they treat with MySQL. If they expect MySQL to pay them $10,000 per installation, and MySQL was paying Heiki $100 per installation, then that would be predatory. OTOH, if they charge the same rate, or some small incremental increase over what innobase charges now, then I'd say no harm no foul. Of course, knowing Oracle, they might want MySQL to pay by the CPU / power rating, etc... Licensing could be the same basic cost it is now, but with so much paper work and documentation so as to be a nightmare. I'm just glad PostgreSQL isn't beholden to licensed / patented software to get the job done... On Mon, 2005-10-10 at 12:47, Marc G. Fournier wrote: > Stupid question here, but how susceptible is Oracle to "monopolistic > practices", similar to what M$ is going through with the DoJ in the US? > This seems to be *very* close to the line, if it isn't over it ... no? > > On Mon, 10 Oct 2005, Dann Corbit wrote: > > > From: > > http://www.filmsite.org/whof4.html > > > > Valiant: Come on. Nobody's gonna drive this lousy freeway when they can take the Red Car for a nickel. > > Doom: Oh, they'll drive. They'll have to. You see, I bought the Red Car so I could dismantle it. > > > > I don't think Oracle has any interest in InnoDB other than to pull the rug out from under the commercial version of MySQL. Ranks right up there with MS's gutting of STAK and Sun's claim of language ownership for Java. > > IMO-YMMV. > > ________________________________________ > > From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org] On Behalf Of snacktime > > Sent: Monday, October 10, 2005 10:14 AM > > To: pgsql-general@postgresql.org > > Subject: Re: [GENERAL] Oracle buys Innobase > > > > > > On 10/7/05, Jim C. Nasby <jnasby@pervasive.com> wrote: > > http://lnk.nu/prnewswire.com/4dv.pl > > -- > > Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com > > Pervasive Software http://pervasive.com work: 512-231-6117 > > vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 2: Don't 'kill -9' the postmaster > > > > First thing that comes to my mind is that Oracle is setting the stage to buy them out. > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 3: Have you checked our extensive FAQ? > > > > http://www.postgresql.org/docs/faq > > > > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 > ---------------------------(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
Marc G. Fournier wrote: > > Stupid question here, but how susceptible is Oracle to "monopolistic > practices", similar to what M$ is going through with the DoJ in the > US? This seems to be *very* close to the line, if it isn't over it ... > no? They are not... too many competitors... MS suffers because they are 98% of the desktop. Oracle isn't even close to 98% of the database market. > > On Mon, 10 Oct 2005, Dann Corbit wrote: > >> From: >> http://www.filmsite.org/whof4.html >> >> Valiant: Come on. Nobody's gonna drive this lousy freeway when they >> can take the Red Car for a nickel. >> Doom: Oh, they'll drive. They'll have to. You see, I bought the Red >> Car so I could dismantle it. >> >> I don't think Oracle has any interest in InnoDB other than to pull >> the rug out from under the commercial version of MySQL. Ranks right >> up there with MS's gutting of STAK and Sun's claim of language >> ownership for Java. >> IMO-YMMV. >> ________________________________________ >> From: pgsql-general-owner@postgresql.org >> [mailto:pgsql-general-owner@postgresql.org] On Behalf Of snacktime >> Sent: Monday, October 10, 2005 10:14 AM >> To: pgsql-general@postgresql.org >> Subject: Re: [GENERAL] Oracle buys Innobase >> >> >> On 10/7/05, Jim C. Nasby <jnasby@pervasive.com> wrote: >> http://lnk.nu/prnewswire.com/4dv.pl >> -- >> Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com >> Pervasive Software http://pervasive.com work: 512-231-6117 >> vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 2: Don't 'kill -9' the postmaster >> >> First thing that comes to my mind is that Oracle is setting the stage >> to buy them out. >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 3: Have you checked our extensive FAQ? >> >> http://www.postgresql.org/docs/faq >> > > ---- > Marc G. Fournier Hub.Org Networking Services > (http://www.hub.org) > Email: scrappy@hub.org Yahoo!: yscrappy ICQ: > 7615664 > ---------------------------(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 -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
On Mon, Oct 10, 2005 at 02:47:31PM -0300, Marc G. Fournier wrote: > > Stupid question here, but how susceptible is Oracle to "monopolistic > practices", similar to what M$ is going through with the DoJ in the > US? This seems to be *very* close to the line, if it isn't over it > ... no? It may well be, but somebody would have sue, and then they would have to win against Oracle. I don't think that MySQL AB has the resources to fight such a legal action, even assuming they'd win it. Cheers, D -- David Fetter david@fetter.org http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote!
Consider what happened to Stak verse MS. Stak won the court case but still went out of business. > -----Original Message----- > From: David Fetter [mailto:david@fetter.org] > Sent: Monday, October 10, 2005 11:17 AM > To: Marc G. Fournier > Cc: Dann Corbit; snacktime; pgsql-general@postgresql.org > Subject: Re: [GENERAL] Oracle buys Innobase > > On Mon, Oct 10, 2005 at 02:47:31PM -0300, Marc G. Fournier wrote: > > > > Stupid question here, but how susceptible is Oracle to "monopolistic > > practices", similar to what M$ is going through with the DoJ in the > > US? This seems to be *very* close to the line, if it isn't over it > > ... no? > > It may well be, but somebody would have sue, and then they would have > to win against Oracle. I don't think that MySQL AB has the resources > to fight such a legal action, even assuming they'd win it. > > Cheers, > D > -- > David Fetter david@fetter.org http://fetter.org/ > phone: +1 510 893 6100 mobile: +1 415 235 3778 > > Remember to vote!
On Mon, Oct 10, 2005 at 11:29:24AM -0700, Dann Corbit wrote: > Consider what happened to Stak verse MS. Stak won the court case > but still went out of business. My point exactly ;) Cheers, D > > > -----Original Message----- > > From: David Fetter [mailto:david@fetter.org] > > Sent: Monday, October 10, 2005 11:17 AM > > To: Marc G. Fournier > > Cc: Dann Corbit; snacktime; pgsql-general@postgresql.org > > Subject: Re: [GENERAL] Oracle buys Innobase > > > > On Mon, Oct 10, 2005 at 02:47:31PM -0300, Marc G. Fournier wrote: > > > > > > Stupid question here, but how susceptible is Oracle to "monopolistic > > > practices", similar to what M$ is going through with the DoJ in the > > > US? This seems to be *very* close to the line, if it isn't over it > > > ... no? > > > > It may well be, but somebody would have sue, and then they would have > > to win against Oracle. I don't think that MySQL AB has the resources > > to fight such a legal action, even assuming they'd win it. > > > > Cheers, > > D > > -- > > David Fetter david@fetter.org http://fetter.org/ > > phone: +1 510 893 6100 mobile: +1 415 235 3778 > > > > Remember to vote! -- David Fetter david@fetter.org http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote!
scrappy@postgresql.org ("Marc G. Fournier") writes:
> Stupid question here, but how susceptible is Oracle to "monopolistic
> practices", similar to what M$ is going through with the DoJ in the
> US? This seems to be *very* close to the line, if it isn't over it
> ... no?
No. The market for databases is hardly a monopoly, what with (at the
top end) DB2 and Microsoft SQL Server being actively sold alternatives
to Oracle's products.
Someone might argue that there is a problem, but there would be plenty
of counterevidence to counterargue with.
--
(reverse (concatenate 'string "gro.gultn" "@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/oses.html
Rules of the Evil Overlord #200. "During times of peace, my Legions of
Terror will not be permitted to lie around drinking mead and eating
roast boar. Instead they will be required to obey my dietician and my
aerobics instructor." <http://www.eviloverlord.com/>
On 10/10/2005 1:32 PM, Dann Corbit wrote: > From: > http://www.filmsite.org/whof4.html > > Valiant: Come on. Nobody's gonna drive this lousy freeway when they can take the Red Car for a nickel. > Doom: Oh, they'll drive. They'll have to. You see, I bought the Red Car so I could dismantle it. > > I don't think Oracle has any interest in InnoDB other than to pull the rug out from under the commercial version of MySQL. Ranks right up there with MS's gutting of STAK and Sun's claim of language ownership for Java. > IMO-YMMV. And this might not even be meant personally agains MySQL. There is this old tit for tat between Oracle and SAP, you know? Some of that finger wrestling lead to SAP having this other database, they don't really know what to do with (Adabas-D AKA SAP-DB AKA MaxDB). SAP still owns the rights to that code, but MySQL does all the maintenance and support for it. And as I understood it, there were plans to rebuild the MaxDB functionality in a future version of MySQL because the MaxDB code isn't exactly maintenance friendly. Now here is the price question: How many SAP R/3 customers would chose that new MySQL version over Oracle while Oracle has their hand on that drain plug Innobase? Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
On a side note, have you considered submitting a case study about the work you're doing? One place where MySQL AB and it's zealots likes to beat PostgreSQL over the head is with it's list of clients. It'd be nice to be able to say that the Mayo Clinic is using PostgreSQL. On Mon, Oct 10, 2005 at 09:53:17AM -0500, Dan Armbrust wrote: > Greg Sabino Mullane wrote: > > > >The other answer may be the license: plugging PG into the MySQL system > >(which is about as technically feasible trying to breed a porpoise > >and an elephant) keeps MySQL GPL, which is another reason many people > >like it. > > > > The fact that PostgreSQL is NOT released under GPL is the reason that > people like me are here - MySQL's license drove us away from them. > Their change of the driver licensing prevents us from shipping new > drivers with our applications. > > GPL is a poison pill when it comes to groups like us that are trying to > develop standards (and shared code bases) that can be used by both > opensource and corporate types alike. > > So keep up the good work! > > Dan > > > -- > **************************** > Daniel Armbrust > Biomedical Informatics > Mayo Clinic Rochester > daniel.armbrust(at)mayo.edu > http://informatics.mayo.edu/ > > ---------------------------(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 > -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
Marc G. Fournier wrote: > > Stupid question, but what does MySQL bring to the equation? Why not > just use PostgreSQL in the first place? Simplicity. A huge user base. No one is questioning that pg is a superior product :) http://www.mysql.com/why-mysql/marketshare/ * *with a pinch of salt perhaps
Richard_D_Levine@raytheon.com wrote: > What is Oracle after? Small DB technology? They already have rdb. > Firebird, back in the Groton Database Corporation days, was built to be > compatible with rdb. Marrying those technologies through modification of > existing gateways makes more technological sense than InnoDB. > > Oracle is trying for market share, as they always do, but it appears ill > conceived. MySQL is for people who can't or won't tune and manage a DBMS. > Oracle products are just not going to fit. Both on price and complexity. > If they kill MySQL, they are just going to increase other true FOSS RDBMS > projects' market share. Power to them. Oracle must know that the comodity database days are coming. By attacking MySQL they delay that time by another few quarters, perhaps. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Marc G. Fournier wrote: > > Stupid question here, but how susceptible is Oracle to "monopolistic > practices", similar to what M$ is going through with the DoJ in the US? > This seems to be *very* close to the line, if it isn't over it ... no? > One big issue is that MS has the DOJ watching over it, as the DOJ did to IBM when the PC came out. Oracle doesn't have that oversight, meaning that the database market is more aggressive. --------------------------------------------------------------------------- > On Mon, 10 Oct 2005, Dann Corbit wrote: > > > From: > > http://www.filmsite.org/whof4.html > > > > Valiant: Come on. Nobody's gonna drive this lousy freeway when they can take the Red Car for a nickel. > > Doom: Oh, they'll drive. They'll have to. You see, I bought the Red Car so I could dismantle it. > > > > I don't think Oracle has any interest in InnoDB other than to pull the rug out from under the commercial version of MySQL. Ranks right up there with MS's gutting of STAK and Sun's claim of language ownership for Java. > > IMO-YMMV. > > ________________________________________ > > From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org] On Behalf Of snacktime > > Sent: Monday, October 10, 2005 10:14 AM > > To: pgsql-general@postgresql.org > > Subject: Re: [GENERAL] Oracle buys Innobase > > > > > > On 10/7/05, Jim C. Nasby <jnasby@pervasive.com> wrote: > > http://lnk.nu/prnewswire.com/4dv.pl > > -- > > Jim C. Nasby, Sr. Engineering Consultant??????jnasby@pervasive.com > > Pervasive Software?????? http://pervasive.com????work: 512-231-6117 > > vcard: http://jim.nasby.net/pervasive.vcf?????? cell: 512-569-9461 > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 2: Don't 'kill -9' the postmaster > > > > First thing that comes to my mind is that Oracle is setting the stage to buy them out. > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 3: Have you checked our extensive FAQ? > > > > http://www.postgresql.org/docs/faq > > > > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 > ---------------------------(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 > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Chris Browne wrote:
> uwe@oss4u.com ("Uwe C. Schroeder") writes:
> > On Saturday 08 October 2005 21:07, Chris Browne wrote:
> >> 2. The code base was pretty old, pretty creaky, and has a *really*
> >> heavy learning curve.
> >>
> >> It was pretty famous as being *really* difficult to build; throw
> >> together such things as:
> >> - It uses a custom set of build tools that were created for a
> >> mainframe environment and sorta hacked into Python
> >> - Naming conventions for files, variables, and functions combine
> >> pseudo-German with an affinity for 8 character names that are
> >> anything but mnemonic. (Think: "Germans developing on MVS.")
> >> - I seem to recall there being a Pascal translator to transform
> >> some of the code into C++...
> >
> > WOW - careful now. I'm german - but then, there's a reason why I
> > immigrated to the US :-)
>
> I'm 1/4 German, and a couple brothers married German girls, so I'm not
> trying to be mean, by any stretch.
>
> The bad Procrustean part is the "8 character mainframe" aspect, as it
> takes things that might have been mnemonic, at least to those knowing
> German, and distills things down in size so as to lose even that.
>
> It truly *was* Germans developing on MVS (or TSO or OS/360 or such)...
Just to clarify, directory names are single letters, and file names are
numbers --- I kid you not.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Terence wrote: > > Marc G. Fournier wrote: >> >> Stupid question, but what does MySQL bring to the equation? Why not >> just use PostgreSQL in the first place? > > Simplicity. Simplicity is in the eye of the beholder. Which of a dozen or so different storage engines should I use for table X? If I mix and match these table types, how will the database behave? Personally I find simplicity to be in adherence to the SQL standard as closely as possible. Each database has their extensions, but every time I use MySQL it grates my teeth how much non-standard stuff I have to 'relearn', making the experience anything *but* simple. > A huge user base. While I would love PostgreSQL to be more widely used, I don't think something so ephemeral is necessarily something they "bring to the table". Rather than shoehorn PostgreSQL into MySQL, having good migration tools seems to be the key here. After all, which of these widely used products were replaced, and which were expanded with outside technology: Lotus 1-2-3 Wordperfect IBM PC etc > No one is questioning that pg is a superior product :) As long as PostgreSQL manages to remain an active project with enough contributors to compete on features and/or performance, it doesn't need to attract any more attention than it already does, IMO. Owning a company that relies on PostgreSQL I see some value in more people being experienced with the database when it comes time to hire a DBA, but beyond that, it only needs to be a superior product. Of course when someone /does/ know PostgreSQL, it's usually a sign that they have more than a passing familiarity. I wonder how many MySQL admins are on the same level of proficiency as Windows admins due to ubiquitity. Gregory Wood
On Tuesday 11 October 2005 00:49, Bruce Momjian wrote:
> Richard_D_Levine@raytheon.com wrote:
> > What is Oracle after? Small DB technology? They already have rdb.
> > Firebird, back in the Groton Database Corporation days, was built to be
> > compatible with rdb. Marrying those technologies through modification of
> > existing gateways makes more technological sense than InnoDB.
> >
> > Oracle is trying for market share, as they always do, but it appears ill
> > conceived. MySQL is for people who can't or won't tune and manage a
> > DBMS. Oracle products are just not going to fit. Both on price and
> > complexity. If they kill MySQL, they are just going to increase other
> > true FOSS RDBMS projects' market share. Power to them.
>
> Oracle must know that the comodity database days are coming. By
> attacking MySQL they delay that time by another few quarters, perhaps.
I've been thinking more and more that oracle just want's leverage against
my$ql to force them to live up to thier claims that they "don't compete with
oracle". Ie. there are a few large commercial applications (think erp and
crm) that my$ql has been targeting to be able to support with 5.0 that would
compete directly with oracle (by way of giving those application vendors
leverage to use my$ql instead of oracle). Part of a future licensing
agreement might be that my$ql stay out of those markets.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
On Mon, Oct 10, 2005 at 06:41:42PM -0500, Jim C. Nasby wrote: > On a side note, have you considered submitting a case study about the > work you're doing? One place where MySQL AB and it's zealots likes to > beat PostgreSQL over the head is with it's list of clients. It'd be nice > to be able to say that the Mayo Clinic is using PostgreSQL. You might also want to go ahead asking this guy for information: http://www.coolheads.com/egov/opensource/topicmap/a101/author.html He is active on several open source health software lists that I am on. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
We have entered a new phase in the possible attacks on PostgreSQL.
The purchase of InnoDB clearly shows Oracle is ready to expend money to
slow down competitive database technology. Now that MySQL has been
attacked, we should expect to be the next target.
Let's assume Oracle is willing to spend 1% of their revenue or net
income on attacking PostgreSQL. Given this financial statement:
http://finance.yahoo.com/q/is?s=ORCL&annual
that would be USD $20-100 million. (The Oracle financial statement will
eventually disclose the purchase price of InnoDB, and we can use that as
a minimum amount they would be willing to spend.)
Now, I think Oracle realizes that the database will eventually become a
commodity based on their purchase of Peoplesoft and other application
technology. However, every financial period they delay that time is
more profit for them, so it is a cost/benefit of how much it is worth to
slow down PostgreSQL. Obviously they thought the InnoDB purchase was
worth it to slow down or control MySQL. Our goal should be to make the
cost of attacks higher than the benefit.
Here are the three most likely attacks on our project:
o Hiring
Oracle could hire a large portion of our paid or volunteer developers,
thereby slowing down the project. Individuals would probably be
approach as "We like your work on PostgreSQL and would like your
expertise in improving Oracle", but of course once hired what they did
for Oracle would be unimportant. What would be important is what they
_don't_ do for PostgreSQL.
o Trademark
Marc Fournier owns the PostgreSQL trademark and domain names. He could
be attacked, perhaps by hiring him to do a job, causing it to fail, then
suing him to obtain the trademark, and therefore the right to own the
domain names. The trademark has not been enforced, and it would be hard
to enforce at this stage, but I think it would be effective in gaining
control of the domain names.
o Patents
Most technology people agree the software patent system is broken, but
it could be a potent weapon against us, though we have shown we can
efficiently remove patent issue from our code.
There is probably nothing Oracle can do to permanently harm us, but
there are a variety of things they can do to temporarily slow us down,
and it is likely a attempt will be made in the future. There are also
possible threats to PostgreSQL support companies, though they are
somewhat independent of the project.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Of course one flip-side to all this is that if Oracle does attack us it actually lends credibility; it means they see PostgreSQL as a threat. At this point that could do more good for us than harm, depending on how exactly the attacked. On Tue, Oct 11, 2005 at 06:04:40PM -0400, Bruce Momjian wrote: > We have entered a new phase in the possible attacks on PostgreSQL. > > The purchase of InnoDB clearly shows Oracle is ready to expend money to > slow down competitive database technology. Now that MySQL has been > attacked, we should expect to be the next target. > > Let's assume Oracle is willing to spend 1% of their revenue or net > income on attacking PostgreSQL. Given this financial statement: > > http://finance.yahoo.com/q/is?s=ORCL&annual > > that would be USD $20-100 million. (The Oracle financial statement will > eventually disclose the purchase price of InnoDB, and we can use that as > a minimum amount they would be willing to spend.) > > Now, I think Oracle realizes that the database will eventually become a > commodity based on their purchase of Peoplesoft and other application > technology. However, every financial period they delay that time is > more profit for them, so it is a cost/benefit of how much it is worth to > slow down PostgreSQL. Obviously they thought the InnoDB purchase was > worth it to slow down or control MySQL. Our goal should be to make the > cost of attacks higher than the benefit. > > Here are the three most likely attacks on our project: > > o Hiring > > Oracle could hire a large portion of our paid or volunteer developers, > thereby slowing down the project. Individuals would probably be > approach as "We like your work on PostgreSQL and would like your > expertise in improving Oracle", but of course once hired what they did > for Oracle would be unimportant. What would be important is what they > _don't_ do for PostgreSQL. > > o Trademark > > Marc Fournier owns the PostgreSQL trademark and domain names. He could > be attacked, perhaps by hiring him to do a job, causing it to fail, then > suing him to obtain the trademark, and therefore the right to own the > domain names. The trademark has not been enforced, and it would be hard > to enforce at this stage, but I think it would be effective in gaining > control of the domain names. > > o Patents > > Most technology people agree the software patent system is broken, but > it could be a potent weapon against us, though we have shown we can > efficiently remove patent issue from our code. > > > There is probably nothing Oracle can do to permanently harm us, but > there are a variety of things they can do to temporarily slow us down, > and it is likely a attempt will be made in the future. There are also > possible threats to PostgreSQL support companies, though they are > somewhat independent of the project. > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup. | Newtown Square, Pennsylvania 19073 > > ---------------------------(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 > -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
Jim C. Nasby wrote: > Of course one flip-side to all this is that if Oracle does attack us it > actually lends credibility; it means they see PostgreSQL as a threat. At > this point that could do more good for us than harm, depending on how > exactly the attacked. Well, that was MySQL's reaction to it, but I think the harm far outweighs the good for them. Its more like, "Oracle finds MySQL a threat, what is MySQL going to do now!" We don't want that kind of outcome. Also, there are ways of attacking that do not show Oracle as an agreesor, like hiring PostgreSQL developers. --------------------------------------------------------------------------- > > On Tue, Oct 11, 2005 at 06:04:40PM -0400, Bruce Momjian wrote: > > We have entered a new phase in the possible attacks on PostgreSQL. > > > > The purchase of InnoDB clearly shows Oracle is ready to expend money to > > slow down competitive database technology. Now that MySQL has been > > attacked, we should expect to be the next target. > > > > Let's assume Oracle is willing to spend 1% of their revenue or net > > income on attacking PostgreSQL. Given this financial statement: > > > > http://finance.yahoo.com/q/is?s=ORCL&annual > > > > that would be USD $20-100 million. (The Oracle financial statement will > > eventually disclose the purchase price of InnoDB, and we can use that as > > a minimum amount they would be willing to spend.) > > > > Now, I think Oracle realizes that the database will eventually become a > > commodity based on their purchase of Peoplesoft and other application > > technology. However, every financial period they delay that time is > > more profit for them, so it is a cost/benefit of how much it is worth to > > slow down PostgreSQL. Obviously they thought the InnoDB purchase was > > worth it to slow down or control MySQL. Our goal should be to make the > > cost of attacks higher than the benefit. > > > > Here are the three most likely attacks on our project: > > > > o Hiring > > > > Oracle could hire a large portion of our paid or volunteer developers, > > thereby slowing down the project. Individuals would probably be > > approach as "We like your work on PostgreSQL and would like your > > expertise in improving Oracle", but of course once hired what they did > > for Oracle would be unimportant. What would be important is what they > > _don't_ do for PostgreSQL. > > > > o Trademark > > > > Marc Fournier owns the PostgreSQL trademark and domain names. He could > > be attacked, perhaps by hiring him to do a job, causing it to fail, then > > suing him to obtain the trademark, and therefore the right to own the > > domain names. The trademark has not been enforced, and it would be hard > > to enforce at this stage, but I think it would be effective in gaining > > control of the domain names. > > > > o Patents > > > > Most technology people agree the software patent system is broken, but > > it could be a potent weapon against us, though we have shown we can > > efficiently remove patent issue from our code. > > > > > > There is probably nothing Oracle can do to permanently harm us, but > > there are a variety of things they can do to temporarily slow us down, > > and it is likely a attempt will be made in the future. There are also > > possible threats to PostgreSQL support companies, though they are > > somewhat independent of the project. > > > > -- > > Bruce Momjian | http://candle.pha.pa.us > > pgman@candle.pha.pa.us | (610) 359-1001 > > + If your life is a hard drive, | 13 Roberts Road > > + Christ can be your backup. | Newtown Square, Pennsylvania 19073 > > > > ---------------------------(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 > > > > -- > Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com > Pervasive Software http://pervasive.com work: 512-231-6117 > vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
John Dean wrote: > Hi > > That is terrific news being a former employee of MySQL - Oracle buys > Innobase. I was never a fan of MySQL, personally but when Marten Mikos and > the rest of the business wonks joined the Company I knew then it was time > to get out. I met the author of Innobase once at the first MySQL employees > meeting. I was asked what for an opinion on Heikki Tuuri. I came straight > to point and told Monty and David (Axmark) that Heikki Tuuri can not be > trusted. It seems I was right. Mr Tuuri has no interest in supporting the > OS commumity. His only interest is in making money. My gut feeling now is > that eventually Oracle will buy off Innobase lock stock and barell Then > Innonbase will get consigned to File 13. I now see MySQL heading for a long > slow death; it couldn't happen to a nicer group of people :) Thank God for > PostreSQL Though some sales folks have unusual perspectives on PostgreSQL (and to sell MySQL it seems almost to be required) most MySQL employees have deep respect for PostgreSQL, almost admiration. At least that has been my experience from the MySQL employees I have met at conferences. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Here is a followup to this email. A few people asked me questions off list, and here are my replies: [ Comment mentioning Open Office and Mozilla have not been attacked.] Cconsider that one thing that has restrained Microsoft (and previously IBM) was US Department of Justice oversight. Oracle does not have such oversight, so they are more likely to act aggressively. Basically, just because attacks have not happened in the Linux or Open Office areas (Microsoft territory) does not mean they will not happen in the database area. Oracle has a history of aggressive activity, and it has shown with MySQL now. I doubt many would have thought Oracle would have purchased technology that MySQL depends upon before it happened. Oracle certainly will not win, and I think they know that, but as project leaders, we should try to be defensive to prevent attacks from inflicting harm to the project. [ Comment asking what we can do to protect ourselves.] We can't do much, actually. The trademark thing can be secured, but other than that, I see no other defenses we could use. We can't prevent people from being hired, and we can't guard against patent attacks. I am willing to write up something for our web site if people think that would be helpful. --------------------------------------------------------------------------- Bruce Momjian wrote: > We have entered a new phase in the possible attacks on PostgreSQL. > > The purchase of InnoDB clearly shows Oracle is ready to expend money to > slow down competitive database technology. Now that MySQL has been > attacked, we should expect to be the next target. > > Let's assume Oracle is willing to spend 1% of their revenue or net > income on attacking PostgreSQL. Given this financial statement: > > http://finance.yahoo.com/q/is?s=ORCL&annual > > that would be USD $20-100 million. (The Oracle financial statement will > eventually disclose the purchase price of InnoDB, and we can use that as > a minimum amount they would be willing to spend.) > > Now, I think Oracle realizes that the database will eventually become a > commodity based on their purchase of Peoplesoft and other application > technology. However, every financial period they delay that time is > more profit for them, so it is a cost/benefit of how much it is worth to > slow down PostgreSQL. Obviously they thought the InnoDB purchase was > worth it to slow down or control MySQL. Our goal should be to make the > cost of attacks higher than the benefit. > > Here are the three most likely attacks on our project: > > o Hiring > > Oracle could hire a large portion of our paid or volunteer developers, > thereby slowing down the project. Individuals would probably be > approach as "We like your work on PostgreSQL and would like your > expertise in improving Oracle", but of course once hired what they did > for Oracle would be unimportant. What would be important is what they > _don't_ do for PostgreSQL. > > o Trademark > > Marc Fournier owns the PostgreSQL trademark and domain names. He could > be attacked, perhaps by hiring him to do a job, causing it to fail, then > suing him to obtain the trademark, and therefore the right to own the > domain names. The trademark has not been enforced, and it would be hard > to enforce at this stage, but I think it would be effective in gaining > control of the domain names. > > o Patents > > Most technology people agree the software patent system is broken, but > it could be a potent weapon against us, though we have shown we can > efficiently remove patent issue from our code. > > > There is probably nothing Oracle can do to permanently harm us, but > there are a variety of things they can do to temporarily slow us down, > and it is likely a attempt will be made in the future. There are also > possible threats to PostgreSQL support companies, though they are > somewhat independent of the project. > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup. | Newtown Square, Pennsylvania 19073 > > ---------------------------(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 > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Tue, Oct 11, 2005 at 06:31:06PM -0400, Bruce Momjian wrote: > Jim C. Nasby wrote: > > Of course one flip-side to all this is that if Oracle does attack us it > > actually lends credibility; it means they see PostgreSQL as a threat. At > > this point that could do more good for us than harm, depending on how > > exactly the attacked. > > Well, that was MySQL's reaction to it, but I think the harm far > outweighs the good for them. Its more like, "Oracle finds MySQL a > threat, what is MySQL going to do now!" We don't want that kind of > outcome. Also, there are ways of attacking that do not show Oracle as > an agreesor, like hiring PostgreSQL developers. Well, they effectively took a big chunk of MySQL's commercial technology away, something the'd have a harder time doing with PostgreSQL (unless we're violating patents). -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
On Tue, Oct 11, 2005 at 06:52:16PM -0400, Bruce Momjian wrote: > We can't do much, actually. The trademark thing can be secured, but > other than that, I see no other defenses we could use. We can't prevent > people from being hired, and we can't guard against patent attacks. Actually, I think there's things that can be done in both cases. For patents, we need to ensure that we're not using technology that's covered by patents. But even so, this is really more of an issue for commercial entities using PostgreSQL. There's not very much Oracle could go after in the community. As for developers, the way that can be defended against is by keeping the developers in demand at companies that are commercializing PostgreSQL. The way that's done is by supporting those companies so that they're PostgreSQL operations are profitable and they have the desire to keep their talent around. Granted, Oracle has more money laying around than probably all current commercial ventures combined, but I would venture to guess that most people in the community would be very hesitant to even consider a job at Oracle. As an ironic aside, I actually turned down a job at Oracle about 18 months ago. Before anyone worries though, it was offered by a friend and PostgreSQL wasn't an issue at all. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
> [ Comment asking what we can do to protect ourselves.] > > We can't do much, actually. The trademark thing can be secured, but > other than that, I see no other defenses we could use. We can't prevent > people from being hired, and we can't guard against patent attacks. Seems you could argue that if the success of the postgresql project is in the hands of so few then we've got issues regardless of Oracle. Those people could (heaven forbid) get hit by the proverbial bus. It would have the same effect on postgresql itself. Anyway, just something to keep in mind... > I am willing to write up something for our web site if people think that > would be helpful. I think it it might be worth mentioning (in response to the mysql/innodb/oracle issue) that there's nothing for Oracle to purchase that would limit postgresql in the future -- that postgresql doesn't rely on any commercially licensed code the removal of which would adversely affect postgresql itself. Anyway, that's my little 2 cents... :) -philip
On 10/11/2005 6:31 PM, Bruce Momjian wrote: > Jim C. Nasby wrote: >> Of course one flip-side to all this is that if Oracle does attack us it >> actually lends credibility; it means they see PostgreSQL as a threat. At >> this point that could do more good for us than harm, depending on how >> exactly the attacked. > > Well, that was MySQL's reaction to it, but I think the harm far > outweighs the good for them. Its more like, "Oracle finds MySQL a > threat, what is MySQL going to do now!" We don't want that kind of > outcome. Also, there are ways of attacking that do not show Oracle as > an agreesor, like hiring PostgreSQL developers. From the fact that there was first an Oracle announcement and then some "calming words" from MySQL we can tell that this wasn't friendly. If it would have been, they would have had a joint press release instead of this big grin from Oracle and that clenched teeth smile from MySQL in return. So I agree, they are in deep trouble. Now the much I agree that we should be carefull and watch out, I don't think we should be jumping to conclusions either. Nobody outside Oracle knows right now what their real plan and their real target with that acquisition is. Don't forget that only a part, although a substantial part, of Oracles revenue comes out of the database business. One possibility is that they try to do birth control against a low-cost R/3 backend, which undoubtedly would be very bad for their CRM and ERP business in several ways. After failing to build any open source community, SAP had found MySQL, who was willing to maintain the SAP-DB sourcecode for them. If Oracle squishes MySQL now, SAP is back to square one on that project. There are many R/3 installations out there that go well beyond 1/4 million dollars per year in DB license fees alone. So even if they can only delay this development by two to three years, it might pay off quite well. And look at it, all Oracle would have to do is to be so open source friendly that they make InnoDB GPL only. Can you imagine the confusion in the MySQL fan club if Oracle releases the next GPL version of InnoDB and MySQL AB announces that they ripped out InnoDB support and favor something with half the feature set instead? Jan > > --------------------------------------------------------------------------- > > >> >> On Tue, Oct 11, 2005 at 06:04:40PM -0400, Bruce Momjian wrote: >> > We have entered a new phase in the possible attacks on PostgreSQL. >> > >> > The purchase of InnoDB clearly shows Oracle is ready to expend money to >> > slow down competitive database technology. Now that MySQL has been >> > attacked, we should expect to be the next target. >> > >> > Let's assume Oracle is willing to spend 1% of their revenue or net >> > income on attacking PostgreSQL. Given this financial statement: >> > >> > http://finance.yahoo.com/q/is?s=ORCL&annual >> > >> > that would be USD $20-100 million. (The Oracle financial statement will >> > eventually disclose the purchase price of InnoDB, and we can use that as >> > a minimum amount they would be willing to spend.) >> > >> > Now, I think Oracle realizes that the database will eventually become a >> > commodity based on their purchase of Peoplesoft and other application >> > technology. However, every financial period they delay that time is >> > more profit for them, so it is a cost/benefit of how much it is worth to >> > slow down PostgreSQL. Obviously they thought the InnoDB purchase was >> > worth it to slow down or control MySQL. Our goal should be to make the >> > cost of attacks higher than the benefit. >> > >> > Here are the three most likely attacks on our project: >> > >> > o Hiring >> > >> > Oracle could hire a large portion of our paid or volunteer developers, >> > thereby slowing down the project. Individuals would probably be >> > approach as "We like your work on PostgreSQL and would like your >> > expertise in improving Oracle", but of course once hired what they did >> > for Oracle would be unimportant. What would be important is what they >> > _don't_ do for PostgreSQL. >> > >> > o Trademark >> > >> > Marc Fournier owns the PostgreSQL trademark and domain names. He could >> > be attacked, perhaps by hiring him to do a job, causing it to fail, then >> > suing him to obtain the trademark, and therefore the right to own the >> > domain names. The trademark has not been enforced, and it would be hard >> > to enforce at this stage, but I think it would be effective in gaining >> > control of the domain names. >> > >> > o Patents >> > >> > Most technology people agree the software patent system is broken, but >> > it could be a potent weapon against us, though we have shown we can >> > efficiently remove patent issue from our code. >> > >> > >> > There is probably nothing Oracle can do to permanently harm us, but >> > there are a variety of things they can do to temporarily slow us down, >> > and it is likely a attempt will be made in the future. There are also >> > possible threats to PostgreSQL support companies, though they are >> > somewhat independent of the project. >> > >> > -- >> > Bruce Momjian | http://candle.pha.pa.us >> > pgman@candle.pha.pa.us | (610) 359-1001 >> > + If your life is a hard drive, | 13 Roberts Road >> > + Christ can be your backup. | Newtown Square, Pennsylvania 19073 >> > >> > ---------------------------(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 >> > >> >> -- >> Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com >> Pervasive Software http://pervasive.com work: 512-231-6117 >> vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 >> > -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
I agree with Jan. I think a good part of this whole situation has more to do with MySQL having a core part of its product be dependent on an external entity. Be they open source or not. I would think they have thought about this possibility at various points in the past. From where I sit, I dont see PostgreSQL having the same situation, but perhaps there's some other ridiculously popular extension to pg which I dont know about. I'd vote for just continuing to make a better product, compete aggressively on the pr front (where pg still has some way to go), and let the best player win. ___________________________________ Javier Soltero Hyperic | www.hyperic.net o- 415 738 2566 | c- 415 305 8733 javier.soltero@hyperic.net ___________________________________ On Oct 11, 2005, at 5:02 PM, Jan Wieck wrote: > On 10/11/2005 6:31 PM, Bruce Momjian wrote: > > >> Jim C. Nasby wrote: >> >>> Of course one flip-side to all this is that if Oracle does attack >>> us it >>> actually lends credibility; it means they see PostgreSQL as a >>> threat. At >>> this point that could do more good for us than harm, depending on >>> how >>> exactly the attacked. >>> >> Well, that was MySQL's reaction to it, but I think the harm far >> outweighs the good for them. Its more like, "Oracle finds MySQL a >> threat, what is MySQL going to do now!" We don't want that kind of >> outcome. Also, there are ways of attacking that do not show >> Oracle as >> an agreesor, like hiring PostgreSQL developers. >> > > From the fact that there was first an Oracle announcement and then > some "calming words" from MySQL we can tell that this wasn't > friendly. If it would have been, they would have had a joint press > release instead of this big grin from Oracle and that clenched > teeth smile from MySQL in return. So I agree, they are in deep > trouble. > > Now the much I agree that we should be carefull and watch out, I > don't think we should be jumping to conclusions either. Nobody > outside Oracle knows right now what their real plan and their real > target with that acquisition is. > > Don't forget that only a part, although a substantial part, of > Oracles revenue comes out of the database business. One possibility > is that they try to do birth control against a low-cost R/3 > backend, which undoubtedly would be very bad for their CRM and ERP > business in several ways. After failing to build any open source > community, SAP had found MySQL, who was willing to maintain the SAP- > DB sourcecode for them. If Oracle squishes MySQL now, SAP is back > to square one on that project. There are many R/3 installations out > there that go well beyond 1/4 million dollars per year in DB > license fees alone. So even if they can only delay this development > by two to three years, it might pay off quite well. > > And look at it, all Oracle would have to do is to be so open source > friendly that they make InnoDB GPL only. Can you imagine the > confusion in the MySQL fan club if Oracle releases the next GPL > version of InnoDB and MySQL AB announces that they ripped out > InnoDB support and favor something with half the feature set instead? > > > Jan > > >> --------------------------------------------------------------------- >> ------ >> >>> On Tue, Oct 11, 2005 at 06:04:40PM -0400, Bruce Momjian wrote: >>> > We have entered a new phase in the possible attacks on PostgreSQL. >>> > > The purchase of InnoDB clearly shows Oracle is ready to >>> expend money to >>> > slow down competitive database technology. Now that MySQL has >>> been >>> > attacked, we should expect to be the next target. >>> > > Let's assume Oracle is willing to spend 1% of their revenue >>> or net >>> > income on attacking PostgreSQL. Given this financial statement: >>> > > http://finance.yahoo.com/q/is?s=ORCL&annual >>> > > that would be USD $20-100 million. (The Oracle financial >>> statement will >>> > eventually disclose the purchase price of InnoDB, and we can >>> use that as >>> > a minimum amount they would be willing to spend.) >>> > > Now, I think Oracle realizes that the database will >>> eventually become a >>> > commodity based on their purchase of Peoplesoft and other >>> application >>> > technology. However, every financial period they delay that >>> time is >>> > more profit for them, so it is a cost/benefit of how much it is >>> worth to >>> > slow down PostgreSQL. Obviously they thought the InnoDB >>> purchase was >>> > worth it to slow down or control MySQL. Our goal should be to >>> make the >>> > cost of attacks higher than the benefit. >>> > > Here are the three most likely attacks on our project: >>> > > o Hiring > > Oracle could hire a large portion of our paid >>> or volunteer developers, >>> > thereby slowing down the project. Individuals would probably be >>> > approach as "We like your work on PostgreSQL and would like your >>> > expertise in improving Oracle", but of course once hired what >>> they did >>> > for Oracle would be unimportant. What would be important is >>> what they >>> > _don't_ do for PostgreSQL. >>> > > o Trademark >>> > > Marc Fournier owns the PostgreSQL trademark and domain >>> names. He could >>> > be attacked, perhaps by hiring him to do a job, causing it to >>> fail, then >>> > suing him to obtain the trademark, and therefore the right to >>> own the >>> > domain names. The trademark has not been enforced, and it >>> would be hard >>> > to enforce at this stage, but I think it would be effective in >>> gaining >>> > control of the domain names. >>> > > o Patents >>> > > Most technology people agree the software patent system is >>> broken, but >>> > it could be a potent weapon against us, though we have shown we >>> can >>> > efficiently remove patent issue from our code. >>> > > > There is probably nothing Oracle can do to permanently harm >>> us, but >>> > there are a variety of things they can do to temporarily slow >>> us down, >>> > and it is likely a attempt will be made in the future. There >>> are also >>> > possible threats to PostgreSQL support companies, though they are >>> > somewhat independent of the project. >>> > > -- > Bruce Momjian | http:// >>> candle.pha.pa.us >>> > pgman@candle.pha.pa.us | (610) 359-1001 >>> > + If your life is a hard drive, | 13 Roberts Road >>> > + Christ can be your backup. | Newtown Square, >>> Pennsylvania 19073 >>> > > ---------------------------(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 >>> > -- >>> Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com >>> Pervasive Software http://pervasive.com work: 512-231-6117 >>> vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 >>> > > > -- > #===================================================================== > =# > # It's easier to get forgiveness for being wrong than for being > right. # > # Let's break this rule - forgive > me. # > #================================================== > JanWieck@Yahoo.com # > > ---------------------------(end of > broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org >
Jan Wieck <JanWieck@Yahoo.com> writes:
> And look at it, all Oracle would have to do is to be so open source
> friendly that they make InnoDB GPL only. Can you imagine the confusion
> in the MySQL fan club if Oracle releases the next GPL version of InnoDB
> and MySQL AB announces that they ripped out InnoDB support and favor
> something with half the feature set instead?
ROTFL ... yes, you would have to give Oracle ten points out of ten for
style, if they did it that way.
regards, tom lane
On Tue, 2005-10-11 at 18:52 -0400, Bruce Momjian wrote: > Oracle certainly will not win, and I think they know that I think this too and that's why I'm here. Best Regards, Simon Riggs
Bruce Momjian wrote: > Marc Fournier owns the PostgreSQL trademark and domain names. Minor point here, but the following domain names: postgresql.com postgres.com postgres.org ... were contributed back to the project by the late Great Bridge LLC, and are registered to the PGDG - with Tom as the admincontact, Marc as the tech contact. Marc/Hub.org has historically owned postgresql.org and postgresql.net, and it lookslike postgres.net got picked up by some guy who's sitting on it. Cheers, Ned
pgsql-general-owner@postgresql.org wrote on 10/11/2005 09:59:16 PM: > Jan Wieck <JanWieck@Yahoo.com> writes: > > And look at it, all Oracle would have to do is to be so open source > > friendly that they make InnoDB GPL only. Can you imagine the confusion > > in the MySQL fan club if Oracle releases the next GPL version of InnoDB > > and MySQL AB announces that they ripped out InnoDB support and favor > > something with half the feature set instead? > > ROTFL ... yes, you would have to give Oracle ten points out of ten for > style, if they did it that way. LOL, a round for the judges. Seriously, all they need to do is drop their caveat to GPL and sell subscriptions instead of licenses. They control all of the source, not taking copyrighted stuff from outside authors. Look but do not touch open source. You want something? Buy a subscription. They are convincing people to buy licenses, not much of a stretch to go to subscriptions. That is a winning scenario for everyone, except maybe Oracle. Cheers, Rick > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org
Ned, > and it looks like postgres.net got picked up by some > guy who's sitting on it. yeah, I'm not sure what he wants. Postgres.net currently directs people to PostgreSQL.org, and I've offered the contact of record money to buy it off him, with no response. -- --Josh Josh Berkus Aglio Database Solutions San Francisco
Hi, Well, if the PostgreSQL developers would be hired away from the project with big money, would that not mean, that the project would be a good path to earn a lot of money. So, new talented developers could join the project and see that as a path to high salary jobs?? Rgs, Jussi Bruce Momjian wrote: >Here is a followup to this email. A few people asked me questions off >list, and here are my replies: > >[ Comment mentioning Open Office and Mozilla have not been attacked.] > >Cconsider that one thing that has restrained Microsoft (and previously >IBM) was US Department of Justice oversight. Oracle does not have such >oversight, so they are more likely to act aggressively. Basically, just >because attacks have not happened in the Linux or Open Office areas >(Microsoft territory) does not mean they will not happen in the database >area. Oracle has a history of aggressive activity, and it has shown >with MySQL now. I doubt many would have thought Oracle would have >purchased technology that MySQL depends upon before it happened. > >Oracle certainly will not win, and I think they know that, but as >project leaders, we should try to be defensive to prevent attacks from >inflicting harm to the project. > >[ Comment asking what we can do to protect ourselves.] > >We can't do much, actually. The trademark thing can be secured, but >other than that, I see no other defenses we could use. We can't prevent >people from being hired, and we can't guard against patent attacks. > >I am willing to write up something for our web site if people think that >would be helpful. > >--------------------------------------------------------------------------- > >Bruce Momjian wrote: > > >>We have entered a new phase in the possible attacks on PostgreSQL. >> >>The purchase of InnoDB clearly shows Oracle is ready to expend money to >>slow down competitive database technology. Now that MySQL has been >>attacked, we should expect to be the next target. >> >>Let's assume Oracle is willing to spend 1% of their revenue or net >>income on attacking PostgreSQL. Given this financial statement: >> >> http://finance.yahoo.com/q/is?s=ORCL&annual >> >>that would be USD $20-100 million. (The Oracle financial statement will >>eventually disclose the purchase price of InnoDB, and we can use that as >>a minimum amount they would be willing to spend.) >> >>Now, I think Oracle realizes that the database will eventually become a >>commodity based on their purchase of Peoplesoft and other application >>technology. However, every financial period they delay that time is >>more profit for them, so it is a cost/benefit of how much it is worth to >>slow down PostgreSQL. Obviously they thought the InnoDB purchase was >>worth it to slow down or control MySQL. Our goal should be to make the >>cost of attacks higher than the benefit. >> >>Here are the three most likely attacks on our project: >> >>o Hiring >> >>Oracle could hire a large portion of our paid or volunteer developers, >>thereby slowing down the project. Individuals would probably be >>approach as "We like your work on PostgreSQL and would like your >>expertise in improving Oracle", but of course once hired what they did >>for Oracle would be unimportant. What would be important is what they >>_don't_ do for PostgreSQL. >> >>o Trademark >> >>Marc Fournier owns the PostgreSQL trademark and domain names. He could >>be attacked, perhaps by hiring him to do a job, causing it to fail, then >>suing him to obtain the trademark, and therefore the right to own the >>domain names. The trademark has not been enforced, and it would be hard >>to enforce at this stage, but I think it would be effective in gaining >>control of the domain names. >> >>o Patents >> >>Most technology people agree the software patent system is broken, but >>it could be a potent weapon against us, though we have shown we can >>efficiently remove patent issue from our code. >> >> >>There is probably nothing Oracle can do to permanently harm us, but >>there are a variety of things they can do to temporarily slow us down, >>and it is likely a attempt will be made in the future. There are also >>possible threats to PostgreSQL support companies, though they are >>somewhat independent of the project. >> >>-- >> Bruce Momjian | http://candle.pha.pa.us >> pgman@candle.pha.pa.us | (610) 359-1001 >> + If your life is a hard drive, | 13 Roberts Road >> + Christ can be your backup. | Newtown Square, Pennsylvania 19073 >> >>---------------------------(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 Wed, 12 Oct 2005, Jussi Mikkola wrote: > Hi, > > Well, if the PostgreSQL developers would be hired away from the project with > big money, would that not mean, that the project would be a good path to earn > a lot of money. So, new talented developers could join the project and see > that as a path to high salary jobs?? Wow, what a twisted way to look at it ... not entirely inaccurate, but twisted :) ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On 10/12/2005 6:18 PM, Marc G. Fournier wrote: > On Wed, 12 Oct 2005, Jussi Mikkola wrote: > >> Hi, >> >> Well, if the PostgreSQL developers would be hired away from the project with >> big money, would that not mean, that the project would be a good path to earn >> a lot of money. So, new talented developers could join the project and see >> that as a path to high salary jobs?? > > Wow, what a twisted way to look at it ... not entirely inaccurate, but > twisted :) Oracle could even develop an exceptional interest in keeping PostgreSQL alive as it's "future DB engineer forge". Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
On Wed, 12 Oct 2005, Jan Wieck wrote: > Oracle could even develop an exceptional interest in keeping PostgreSQL > alive as it's "future DB engineer forge". Jan, Or, to demonstrate that it's not a monopoly. There will be two choices: Oracle and postgres. Rich -- Dr. Richard B. Shepard, President | 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
On Wed, 12 Oct 2005, Jan Wieck wrote: > On 10/12/2005 6:18 PM, Marc G. Fournier wrote: > >> On Wed, 12 Oct 2005, Jussi Mikkola wrote: >> >>> Hi, >>> >>> Well, if the PostgreSQL developers would be hired away from the project >>> with big money, would that not mean, that the project would be a good path >>> to earn a lot of money. So, new talented developers could join the project >>> and see that as a path to high salary jobs?? >> >> Wow, what a twisted way to look at it ... not entirely inaccurate, but >> twisted :) > > Oracle could even develop an exceptional interest in keeping PostgreSQL alive > as it's "future DB engineer forge". Definitely ... get new developers involved over here to 'cut their teeth' and then pull them over there once they are through the teething period :) Or, encourage them to work here wihle still in University, learn DB internals ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
As much as I respect Marc and Postgresql.org, I can't see Oracle hiring him away as a "killer" threat to the community. People would set up camp somewhere else, like Command Prompt. It would hurt things for a while but the software is too important to too many to be killed by a domain name or person. On Oct 12, 2005, at 8:47 PM, Marc G. Fournier wrote: > On Wed, 12 Oct 2005, Jan Wieck wrote: > >> On 10/12/2005 6:18 PM, Marc G. Fournier wrote: >> >>> On Wed, 12 Oct 2005, Jussi Mikkola wrote: >>>> Hi, >>>> Well, if the PostgreSQL developers would be hired away from the >>>> project with big money, would that not mean, that the project would >>>> be a good path to earn a lot of money. So, new talented developers >>>> could join the project and see that as a path to high salary jobs?? >>> Wow, what a twisted way to look at it ... not entirely inaccurate, >>> but twisted :) >> >> Oracle could even develop an exceptional interest in keeping >> PostgreSQL alive as it's "future DB engineer forge". > > Definitely ... get new developers involved over here to 'cut their > teeth' and then pull them over there once they are through the > teething period :) Or, encourage them to work here wihle still in > University, learn DB internals ... > > ---- > Marc G. Fournier Hub.Org Networking Services > (http://www.hub.org) > Email: scrappy@hub.org Yahoo!: yscrappy ICQ: > 7615664 > > ---------------------------(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 >
Matthew Terenzio wrote: > As much as I respect Marc and Postgresql.org, I can't see Oracle hiring > him away as a "killer" threat to the community. People would set up > camp somewhere else, like Command Prompt. It would hurt things for a > while but the software is too important to too many to be killed by a > domain name or person. Right, all these damages are temporary, which is probably why we haven't been attacked yet. --------------------------------------------------------------------------- > > On Oct 12, 2005, at 8:47 PM, Marc G. Fournier wrote: > > > On Wed, 12 Oct 2005, Jan Wieck wrote: > > > >> On 10/12/2005 6:18 PM, Marc G. Fournier wrote: > >> > >>> On Wed, 12 Oct 2005, Jussi Mikkola wrote: > >>>> Hi, > >>>> Well, if the PostgreSQL developers would be hired away from the > >>>> project with big money, would that not mean, that the project would > >>>> be a good path to earn a lot of money. So, new talented developers > >>>> could join the project and see that as a path to high salary jobs?? > >>> Wow, what a twisted way to look at it ... not entirely inaccurate, > >>> but twisted :) > >> > >> Oracle could even develop an exceptional interest in keeping > >> PostgreSQL alive as it's "future DB engineer forge". > > > > Definitely ... get new developers involved over here to 'cut their > > teeth' and then pull them over there once they are through the > > teething period :) Or, encourage them to work here wihle still in > > University, learn DB internals ... > > > > ---- > > Marc G. Fournier Hub.Org Networking Services > > (http://www.hub.org) > > Email: scrappy@hub.org Yahoo!: yscrappy ICQ: > > 7615664 > > > > ---------------------------(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 > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian wrote: >Matthew Terenzio wrote: > > >>As much as I respect Marc and Postgresql.org, I can't see Oracle hiring >>him away as a "killer" threat to the community. People would set up >>camp somewhere else, like Command Prompt. It would hurt things for a >>while but the software is too important to too many to be killed by a >>domain name or person. >> >> > >Right, all these damages are temporary, which is probably why we haven't >been attacked yet. > > > > There are also logistical problems with attacking PostgreSQL because nobody owns it. MySQL was an easy target because of the way they negotiated their business contracts for use of Innodb. PostgreSQL doesn't suffer from that. Our only real, substantiated concern that I can see is the potential for the Software Patent crap. Sincerely, Joshua D. Drake -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
Matthew Terenzio <matt@jobsforge.com> writes:
> As much as I respect Marc and Postgresql.org, I can't see Oracle hiring
> him away as a "killer" threat to the community. People would set up
> camp somewhere else, like Command Prompt. It would hurt things for a
> while but the software is too important to too many to be killed by a
> domain name or person.
Yeah, I was thinking that myself: even if a hostile group managed to
obtain control of the trademark and/or domain name, they could not kill
the project. We'd just regroup under a new name --- it'd slow us down
for a bit, sure, but no more. The project name has changed once
already, remember.
The only serious threat I see on the horizon is patent issues. Again,
I don't think that could kill us over the long term --- we could surely
write our way out of any noncritical patents (see recent ARC fiasco for
a fire drill of this nature), and we ourselves are prior art with which
to defeat any patents on critical algorithms. A patent lawsuit could
certainly hurt us, if only by soaking up the time and attention of key
developers, but I don't think it could kill the project.
regards, tom lane
Right. Though there are attacks, there are no fatal attacks. MySQL has to make money, so they can have fatal attacks. --------------------------------------------------------------------------- Tom Lane wrote: > Matthew Terenzio <matt@jobsforge.com> writes: > > As much as I respect Marc and Postgresql.org, I can't see Oracle hiring > > him away as a "killer" threat to the community. People would set up > > camp somewhere else, like Command Prompt. It would hurt things for a > > while but the software is too important to too many to be killed by a > > domain name or person. > > Yeah, I was thinking that myself: even if a hostile group managed to > obtain control of the trademark and/or domain name, they could not kill > the project. We'd just regroup under a new name --- it'd slow us down > for a bit, sure, but no more. The project name has changed once > already, remember. > > The only serious threat I see on the horizon is patent issues. Again, > I don't think that could kill us over the long term --- we could surely > write our way out of any noncritical patents (see recent ARC fiasco for > a fire drill of this nature), and we ourselves are prior art with which > to defeat any patents on critical algorithms. A patent lawsuit could > certainly hurt us, if only by soaking up the time and attention of key > developers, but I don't think it could kill the project. > > 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 > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Wed, 12 Oct 2005, Joshua D. Drake wrote: > PostgreSQL doesn't suffer from that. Our only real, substantiated > concern that I can see is the potential for the Software Patent crap. Stupid question here ... if Oracle came at us with "the Software Patent crap", is there any "reasonable time" provided to remove it? We've already shown in the past that that isn't a big hurdle, with the ARC stuff, so am just curiuos as to how big a thing the Patent stuff is, or does even that fall under 'temporary setback / inconvience'? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: > On Wed, 12 Oct 2005, Joshua D. Drake wrote: > >> PostgreSQL doesn't suffer from that. Our only real, substantiated >> concern that I can see is the potential for the Software Patent crap. > > > Stupid question here ... if Oracle came at us with "the Software > Patent crap", is there any "reasonable time" provided to remove it? > We've already shown in the past that that isn't a big hurdle, with the > ARC stuff, so am just curiuos as to how big a thing the Patent stuff > is, or does even that fall under 'temporary setback / inconvience'? Depends on them. They can request "Injunctive Relief" but they have a whole bunch of other things they would have to get around... They are more likely to go after Command Prompt, Pervasive and most like EnterpriseDB than anybody. Sincerely, Joshua D. Drake > > ---- > Marc G. Fournier Hub.Org Networking Services > (http://www.hub.org) > Email: scrappy@hub.org Yahoo!: yscrappy ICQ: > 7615664 > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
> Stupid question here ... if Oracle came at us with "the Software Patent > crap", is there any "reasonable time" provided to remove it? We've > already shown in the past that that isn't a big hurdle, with the ARC > stuff, so am just curiuos as to how big a thing the Patent stuff is, or > does even that fall under 'temporary setback / inconvience'? That may depend on what's been patented. In my opinions (and more importantly in the eyes of more than a few intellectual property attorneys) the patent office has granted some very dubious software patents, and a deep pockets patent holder would probably have the upper hand wielding them. -- Mike Nolan
Marc G. Fournier wrote: > On Wed, 12 Oct 2005, Joshua D. Drake wrote: > >> PostgreSQL doesn't suffer from that. Our only real, substantiated >> concern that I can see is the potential for the Software Patent crap. > > > Stupid question here ... if Oracle came at us with "the Software Patent > crap", Personally I think it's quite unlikely Oracle would try attacking any F/OSS project on patent grounds. They've pretty much bet the company on Linux (http://news.zdnet.com/2100-3513_22-5825433.html "Within the next 5 years, half of Oracle's customers may be running Linux, company President Charles Phillips has predicted". With the sensitivity in the community that SCO/Baystar-and-friends created I think that it'd be suicidal for Oracle to start any sort of patent-vs-F/OSS war. Imagine the speculation of whether they'd go after Linux itself next......... My guess is that Oracle simply recognized that the Innobase guys were solid database engineers with a product with a growing customer base in a niche (low end databases) that Oracle didn't have a large presence. Therefore it made sense from both a recruiting and a business growth opportunity to acquire them. On those grounds I could certainly see Oracle buying successful postgresql-based companies -- again, for both the talented people and the proven market for those products. But rather than harm the project, I imagine that would simply create incentives for other talented database developers to join the project.
> Personally I think it's quite unlikely Oracle would try attacking > any F/OSS project on patent grounds. They've pretty much bet > the company on Linux (http://news.zdnet.com/2100-3513_22-5825433.html Linux isn't a competitor, PostgreSQL is. > My guess is that Oracle simply recognized that the Innobase guys > were solid database engineers with a product with a growing customer > base in a niche (low end databases) that Oracle didn't have a large > presence. Oh if the world were that nice. Yes you could be correct but my very strong opinion on this is that they did it because it can set back MySQL for 18-24 months. > > Therefore it made sense from both a recruiting and a > business growth opportunity to acquire them. Oracle isn't interested in the 395.00 market. > > On those grounds I could certainly see Oracle buying successful > postgresql-based companies -- again, for both the talented people > and the proven market for those products. For people maybe, but they really don't need the database. Sincerely, Joshua D. Drake > But rather than > harm the project, I imagine that would simply create incentives > for other talented database developers to join the project. > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
On Fri, 2005-10-14 at 12:18, Ron Mayer wrote: > Marc G. Fournier wrote: > > On Wed, 12 Oct 2005, Joshua D. Drake wrote: > > > >> PostgreSQL doesn't suffer from that. Our only real, substantiated > >> concern that I can see is the potential for the Software Patent crap. > > > > > > Stupid question here ... if Oracle came at us with "the Software Patent > > crap", > > Personally I think it's quite unlikely Oracle would try attacking > any F/OSS project on patent grounds. They've pretty much bet > the company on Linux (http://news.zdnet.com/2100-3513_22-5825433.html > "Within the next 5 years, half of Oracle's customers may be running > Linux, company President Charles Phillips has predicted". With > the sensitivity in the community that SCO/Baystar-and-friends created > I think that it'd be suicidal for Oracle to start any sort of > patent-vs-F/OSS war. Imagine the speculation of whether they'd > go after Linux itself next......... But that's the beauty of buying innobase. Oracle can attack MySQL and still be the F/OSS hero! It's simple. Release the innodb code base under GPL only, no commercial license. Anyone who wants it can use it, but they have to only use it in GPL projects. Then, MySQL has a hard decision, do they continue to make a GPL version of MySQL with innodb and remove the innodb handler from their commercially licensed version of MySQL, or do they pull it altogether. If they leave it in the GPL version then they are encouraging their customers to rexamine their usage and try to use the GPL version. If they pull it, they encourage a fork of the code base by another group who might want to keep innodb and doesn't mind it being all GPL. Of course, this group could then architect a LGPL connect library on their own, and then MySQL would be freely usable with commercial software like it once was. Boom, MySQL loses large amounts of their funding, and Oracle wins a public relations coup by releasing innobase under the GPL and hosting the project on their servers. > My guess is that Oracle simply recognized that the Innobase guys > were solid database engineers with a product with a growing customer > base in a niche (low end databases) that Oracle didn't have a large > presence. There are, I believe, exactly ONE innobase guy, the primary developer. Nice guy, but there are still a lot of issues to be worked out in innodb. Hopefully, Oracle can provide the funding to make it work. It would be great if Oracle paid to fork MySQL to a pure GPL product, producing a new connection lib under LGPL, and hosting the whole thing as a version of MySQL that ONLY uses innodb. By forcing it to use one and only one table handler, they would then focus development effort on SQL compliance, proper operation, and adding features that work with innodb, like full text searching. Since the basic database would retain a good amount of interoperability with the old MySQL, this new database could easily take away a fair share of their market. Then, Oracle could sell support contracts, not licenses, and back them up with their rather large corporate infrastructure. > On those grounds I could certainly see Oracle buying successful > postgresql-based companies -- again, for both the talented people > and the proven market for those products. But rather than > harm the project, I imagine that would simply create incentives > for other talented database developers to join the project. Yeah, I'd see it something like that, with the focus being on selling consulting services for folks using PostgreSQL...
Scott Marlowe <smarlowe@g2switchworks.com> writes:
> It would be great if Oracle paid to fork MySQL to a pure GPL product,
> producing a new connection lib under LGPL, and hosting the whole thing
> as a version of MySQL that ONLY uses innodb.
> By forcing it to use one and only one table handler, they would then
> focus development effort on SQL compliance, proper operation, and adding
> features that work with innodb, like full text searching. Since the
> basic database would retain a good amount of interoperability with the
> old MySQL, this new database could easily take away a fair share of
> their market. Then, Oracle could sell support contracts, not licenses,
> and back them up with their rather large corporate infrastructure.
That's a really interesting angle --- not only does Oracle get rid of
what they may or may not see as serious competition, but they get a
chance to make some money at the same time. I'm not convinced about the
"only one table handler" part of your story. Oracle certainly has the
resources to fix up multiple handlers if they wish, and they wouldn't
want to leave a loophole that MySQL AB could use to claim that their
version is better. The only one I'd see them dropping, in this
scenario, is BDB (unless they could buy out Sleepycat too, which is
perhaps not out of the question).
I've been trying to figure out what it is that Oracle gets out of this,
assuming that they don't see MySQL as a serious threat to their core
business. The most they can do is force MySQL AB to waste a year or so
reimplementing something equivalent to InnoDB; which would hurt them but
it's hardly likely to kill them. But with your scenario Oracle might
actually make money out of the deal, which makes it make some sense.
regards, tom lane
Joshua D. Drake wrote: >[Ron Mayer wrote] >>...Oracle...recognized...solid database engineers with >>a product with a growing customer base... >>...made sense from both a recruiting and a >>business growth opportunity to acquire them. > > Oracle isn't interested in the 395.00 market. I think it's the larger MySQL customers (US Census Department, etc) that they are interested in. If the Census Department needs to look outside Oracle for low-end databases, that opens the door to Access / SQL-Server / etc - which really is a threat to Oracle. On the other hand, if the Census Department can get all of their database needs from Oracle, it's a much safer world for Oracle Corp. >>On those grounds I could certainly see Oracle buying successful >>postgresql-based companies -- again, for both the talented people >>and the proven market for those products. > > For people maybe, but they really don't need the database. Not the database itself, as much as the business knowledge of how to sell low-end databases. MySQL has a nice set of reference customers (MySQL AB's claims include Google, US Census Bureau, Yahoo, Sabre, CERN, NASA, Associated Press, Macys, Cox, Cable&Wireless, Nokia, Cisco, Sony, etc) - along with a proven business structure (combination of product + marketing) that appeals enough to those customers to buy it. Sure, Oracle was probably in 90% of those places anyway - but clearly those existing customeres saw the need for a low-end database that wasn't covered by Oracle's existing offerings. Even if Oracle gets little revenue from the low-end-DB-sales to those guys; if it keeps integration between the Census Department's MySQL databases and Oracle-Expensive working reliably, it's worth doing. I'd suspect that any single postgresql-support company that had a similar customer list would get offers from Oracle as well
> MySQL has a nice set of reference customers (MySQL AB's claims > include Google, US Census Bureau, Yahoo, Sabre, CERN, NASA, Associated > Press, Macys, Cox, Cable&Wireless, Nokia, Cisco, Sony, etc) - along > with a proven business structure (combination of product + marketing) You do know that many of those listed above also use PostgreSQL :) Sincerely, Joshua D. Drake -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
On Fri, Oct 14, 2005 at 01:02:00PM -0700, Ron Mayer wrote:
> I'd suspect that any single postgresql-support company that had a
> similar customer list would get offers from Oracle as well
PostgreSQL support companies don't have the leverage that Oracle and
MySQL do to get their clients to "come out of the closet". There
_are_ such customer lists, but the license for PostgreSQL doesn't
entail that those customers be used as marketing fodder.
A
--
Andrew Sullivan | ajs@crankycanuck.ca
"The year's penultimate month" is not in truth a good way of saying
November.
--H.W. Fowler
Joshua D. Drake wrote: > Bruce Momjian wrote: > >> Matthew Terenzio wrote: >> >> >>> As much as I respect Marc and Postgresql.org, I can't see Oracle >>> hiring him away as a "killer" threat to the community. People would >>> set up camp somewhere else, like Command Prompt. It would hurt >>> things for a while but the software is too important to too many to >>> be killed by a domain name or person. >>> >> >> >> Right, all these damages are temporary, which is probably why we haven't >> been attacked yet. >> >> >> >> > There are also logistical problems with attacking PostgreSQL because > nobody owns it. > MySQL was an easy target because of the way they negotiated their > business contracts > for use of Innodb. > > PostgreSQL doesn't suffer from that. Our only real, substantiated > concern that I can see > is the potential for the Software Patent crap. > > Sincerely, > > Joshua D. Drake > But what if they came in sideways and bought Command Prompt? (As an example.) You could do a lot more to destroy PostgreSQL's market in the business world by destroying the various support mechanisms. Your business is much closer to eating their lunch than PostgreSQL itself. So what if they bought Command Prompt (or someone else like it) and then cut it off at the knees? No one ever accused Larry Ellison of being dumb ... different strategies for different opponents. Jeff
> But what if they came in sideways and bought Command Prompt? Well then I would be sitting on a beach in New Zealend with an umbrella drink :) > (As an > example.) You could do a lot more to destroy PostgreSQL's market in the > business world by destroying the various support mechanisms. Your > business is much closer to eating their lunch than PostgreSQL itself. That is a farily good point but one of the beautiful things about Open Source is that even if they bought Command Prompt, they would also have to buy Pervasive and EnterpriseDB and GreenPlum and SRA. And then -- by doing so they are just opening the market for a new set of companies to start supporting PostgreSQL. > So what if they bought Command Prompt (or someone else like it) and then > cut it off at the knees? No one ever accused Larry Ellison of being > dumb ... different strategies for different opponents. No, Larry isn't dumb. You don't get to be the second richest man in the world by being dumb. However he is very strategic and I don't see (at this point) a strategic reason to attack PostgreSQL via Oracle. PostgreSQL at this point is actually a good value add to the Oracle proposition. In 5 years we are probably going to be a immediate direct threat but not right now. Sincerely, Joshua D. Drake > > Jeff > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
There are some articles on eweek about this: Oracle Finds the Flaw in MySQL's Business Plan http://www.eweek.com/article2/0,1895,1869989,00.asp "This is what Oracle says in its release: "InnoDB's contractual relationship with MySQL comes up for renewal next year. Oracle fully expects to negotiate an extension of that relationship." This is what Lubet, former Oracle sales mistress, has to say about that: "I'm pretty sure, as an ex-Oracle employee, that the sentence in the release about 'We'll certainly be happy to renew the contract,' that it was written by Larry and that he was laughing out loud as he [dictated it]." __________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/
CSN wrote: > There are some articles on eweek about this: > > Oracle Finds the Flaw in MySQL's Business Plan > http://www.eweek.com/article2/0,1895,1869989,00.asp > > "This is what Oracle says in its release: "InnoDB's > contractual relationship with MySQL comes up for > renewal next year. Oracle fully expects to negotiate > an extension of that relationship." > > This is what Lubet, former Oracle sales mistress, has > to say about that: "I'm pretty sure, as an ex-Oracle > employee, that the sentence in the release about > 'We'll certainly be happy to renew the contract,' that > it was written by Larry and that he was laughing out > loud as he [dictated it]." Maybe they lost the development of the know how for the only transaction safe table type of the current mysql releases, but they still "own" the former Adabas/MaxDB/SAP-DB code with transaction safe tables. Probably they force the "union" of mysql and SAP-DB code base to keep their transaction competence, but this are just my €0,02... Greetings from Berlin, -tb -- Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
On 10/15/2005 6:22 AM, Thomas Beutin wrote: > Maybe they lost the development of the know how for the only transaction > safe table type of the current mysql releases, but they still "own" the > former Adabas/MaxDB/SAP-DB code with transaction safe tables. Probably > they force the "union" of mysql and SAP-DB code base to keep their > transaction competence, but this are just my €0,02... First, InnoDB is not the only transaction safe table type in MySQL. Although a poor stepchild today, there is still BDB. Second, MySQL AB does not own the MaxDB code. I never fully understood what that contract was about, maybe someone from MySQL AB can explain that, but to my knowledge SAP AG did not transfer the copyright. They could also go back to NuSphere, aka Multera, aka PeerDirect and ask what happened to the Progress storage engine Rocket. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
Andrew Sullivan wrote: >> On Fri, Oct 14, 2005 at 01:02:00PM -0700, Ron Mayer wrote: >> >>>I'd suspect that any single postgresql-support company that had a >>>similar customer list would get offers from Oracle as well >> >> PostgreSQL support companies don't have the leverage that Oracle and >> MySQL do to get their clients to "come out of the closet". There >> _are_ such customer lists, but the license for PostgreSQL doesn't >> entail that those customers be used as marketing fodder. Agreed, but I think my point still stands -- any PostgreSQL company with such customer lists who wants to get bought by Oracle could probably do so easily just by firing off an email to the right person. Oracle likes sales channels into such customers; and likes growing through acquisitions. Heck, they bought 10 (11 counting Innobase?) companies already during just 6 months of this year: http://www.eweek.com/article2/0,1895,1861215,00.asp " Oracle announced its 10th acquisition in six months Tuesday at its annual OpenWorld conference in San Francisco." And they don't even seem to care if the underlying engine is theirs or a competitor. They probably even support DB2 now, thanks to their Siebel, Retek, I-Flex and PeopleSoft acquisitions. Joshua D. Drake wrote: >>>MySQL has a nice set of reference customers (MySQL AB's claims >>>include Google, US Census Bureau, Yahoo, Sabre, CERN, NASA, Associated >>>Press, Macys, Cox, Cable&Wireless, Nokia, Cisco, Sony, etc) - along >>>with a proven business structure (combination of product + marketing) >> >> You do know that many of those listed above also use PostgreSQL :) Sure. I know that some of them (Cisco, at least) sell products based on postgresql; and from first hand experience know another uses it for some really big databases. I'm sure most of them also use BDB and Access and their-own flat-files as well. The difference is when the US Census Bureau (a heavy Oracle user) has a many million dollar budget for databases, and requests bids from dtabase vendors. It would be very nice for Oracle to be able to say things like "yes, we can supply all your needs as opposed to having to go to multiple vendors". Whether the census department sues PostgreSQL or GPL-MySQL or BDB internally doesn't affect Oracle much, since the dollars are really in the high-end systems. But conceding that the Census department needs to look elsewhere for commercial database vendors (which opens the door for those guys with Access/SQLServer) to meet their database needs must really hurt.
>> >> This is what Lubet, former Oracle sales mistress, has >> to say about that: "I'm pretty sure, as an ex-Oracle >> employee, that the sentence in the release about >> 'We'll certainly be happy to renew the contract,' that >> it was written by Larry and that he was laughing out >> loud as he [dictated it]." > > Maybe they lost the development of the know how for the only > transaction safe table type of the current mysql releases, but they > still "own" the former Adabas/MaxDB/SAP-DB code with transaction safe > tables. Probably they force the "union" of mysql and SAP-DB code base > to keep their transaction competence, but this are just my €0,02... They do not "own" MaxDB. They license it, just like Innodb. Sincerely, Joshua D. Drake > > Greetings from Berlin, > -tb -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
On Fri, Oct 14, 2005 at 01:24:05PM -0700, Joshua D. Drake wrote: > > > MySQL has a nice set of reference customers (MySQL AB's claims > > include Google, US Census Bureau, Yahoo, Sabre, CERN, NASA, Associated > > Press, Macys, Cox, Cable&Wireless, Nokia, Cisco, Sony, etc) - along > > with a proven business structure (combination of product + marketing) > > You do know that many of those listed above also use PostgreSQL :) Do we know that for sure? It'd be damn nice to be able to put that kind of info on our website... -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
On Sat, 15 Oct 2005, Joshua D. Drake wrote: > >>> >>> This is what Lubet, former Oracle sales mistress, has >>> to say about that: "I'm pretty sure, as an ex-Oracle >>> employee, that the sentence in the release about >>> 'We'll certainly be happy to renew the contract,' that >>> it was written by Larry and that he was laughing out >>> loud as he [dictated it]." >> >> Maybe they lost the development of the know how for the only transaction >> safe table type of the current mysql releases, but they still "own" the >> former Adabas/MaxDB/SAP-DB code with transaction safe tables. Probably they >> force the "union" of mysql and SAP-DB code base to keep their transaction >> competence, but this are just my €0,02... > > > They do not "own" MaxDB. They license it, just like Innodb. Damn, do they ever have alot of "loose ends" ... what part, exactly, constitutes "MySQL" vs third party add ons? :) ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Tom Lane wrote: >That's a really interesting angle --- not only does Oracle get rid of >what they may or may not see as serious competition, but they get a >chance to make some money at the same time. I'm not convinced about the >"only one table handler" part of your story. Oracle certainly has the >resources to fix up multiple handlers if they wish, and they wouldn't >want to leave a loophole that MySQL AB could use to claim that their >version is better. The only one I'd see them dropping, in this >scenario, is BDB (unless they could buy out Sleepycat too, which is >perhaps not out of the question). > > There is another possibility too... I don't really see Oracle trying to force MySQL to be GPL-only because that would have the potential to materially harm their own market position. Kill MySQL AB and just maybe the community might become less MySQL AB-centric. What is a larger possibility is to use this to contain MySQL AB. Jack up the license fees to the point that MySQL is no longer the super-low-cost alternative. This would also cut into MySQL's profitability at the same time and help slow down the pace of development. The only real downside is that I could see MySQL developing a FirebirdSQL table handler if too much pressure is put on them. This might actually work OK since Firebird has an embeddable engine. If they do this then Oracle might end up with basically the personnel from the Innobase acquisition and very little else. Of course MySQL has progressed to the point where larger license fees might not alienate too many customers. >I've been trying to figure out what it is that Oracle gets out of this, >assuming that they don't see MySQL as a serious threat to their core >business. The most they can do is force MySQL AB to waste a year or so >reimplementing something equivalent to InnoDB; which would hurt them but >it's hardly likely to kill them. > A year delay with MySQL's pace of development and track record? > But with your scenario Oracle might >actually make money out of the deal, which makes it make some sense. > > I was assuming that this deal was primarily done to scare customers away from using MySQL. The timing could not have been more deliberate-- right before 5.0 is supposed to be released. I think that the first message was to scare business customers away from MySQL. Secondly they may want an additional inroad into FOSS. Third, they may be after personnel (i.e the buyout may be really a hiring bonus). Best Wishes, Chris Travers Metatron Technology Consulting
Attachment
Joshua D. Drake wrote: >>But what if they came in sideways and bought Command Prompt? >> >> > >Well then I would be sitting on a beach in New Zealend with an umbrella >drink :) > > > >> (As an >>example.) You could do a lot more to destroy PostgreSQL's market in the >>business world by destroying the various support mechanisms. Your >>business is much closer to eating their lunch than PostgreSQL itself. >> >> > >That is a farily good point but one of the beautiful things about Open >Source is that even if they bought Command Prompt, they would also have >to buy Pervasive and EnterpriseDB and GreenPlum and SRA. > >And then -- by doing so they are just opening the market for a new set >of companies to start supporting PostgreSQL. > > > >>So what if they bought Command Prompt (or someone else like it) and then >>cut it off at the knees? No one ever accused Larry Ellison of being >>dumb ... different strategies for different opponents. >> >> > >No, Larry isn't dumb. You don't get to be the second richest man in the >world by being dumb. However he is very strategic and I don't see (at >this point) a strategic reason to attack PostgreSQL via Oracle. > > I don't think that PostgreSQL is really on Oracle's radar at the moment. >PostgreSQL at this point is actually a good value add to the Oracle >proposition. In 5 years we are probably going to be a immediate direct >threat but not right now. > > Note that it was a few years ago that MySQL first popped up on Oracle's radar screen enough for them to add migration tools helping people move from MySQL to Oracle. I don't see such tools available currently for PostgreSQL to Oracle migrations at the moment. So I suspect that we are still seen as the little guy :-) The difference is that while we have a smaller number of large users, MySQL has a larger number of smaller users so they technically have better market share numbers *and* they have better plublicity. Best Wishes, Chris Travers Metatron Technology Consulting
Marc G. Fournier wrote: > >> >> >> They do not "own" MaxDB. They license it, just like Innodb. > > > Damn, do they ever have alot of "loose ends" ... what part, exactly, > constitutes "MySQL" vs third party add ons? :) If MaxDB, InnoDB, and DBD engines are all licensed, then they have problems. MyISAM? I think they do own that one.... Best Wishes, Chris Travers Metatron Technology Consulting
On Sun, 16 Oct 2005, Chris Travers wrote: > Marc G. Fournier wrote: > >> >>> >>> >>> They do not "own" MaxDB. They license it, just like Innodb. >> >> >> Damn, do they ever have alot of "loose ends" ... what part, exactly, >> constitutes "MySQL" vs third party add ons? :) > > If MaxDB, InnoDB, and DBD engines are all licensed, then they have problems. Thank god our biggest headaches have been "can we include readline, since its GPL?" and "we need to re-write ARC *just in case* IBM decides to enforce their patent" :)" ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
El Dom 16 Oct 2005 01:20, Chris Travers escribió:
>
> The only real downside is that I could see MySQL developing a
> FirebirdSQL table handler if too much pressure is put on them. This
> might actually work OK since Firebird has an embeddable engine. If they
> do this then Oracle might end up with basically the personnel from the
> Innobase acquisition and very little else. Of course MySQL has
> progressed to the point where larger license fees might not alienate too
> many customers.
I'm not sure, as FireBird has a very difficult to understand license, but
could they enforce there commercial license with the FireBird engine (if they
have it)?
--
select 'mmarques' || '@' || 'unl.edu.ar' AS email;
---------------------------------------------------------
Martín Marqués | Programador, DBA
Centro de Telemática | Administrador
Universidad Nacional
del Litoral
---------------------------------------------------------
On 10/16/2005 5:25 PM, Marc G. Fournier wrote: > On Sun, 16 Oct 2005, Chris Travers wrote: > >> Marc G. Fournier wrote: >> >>> >>>> >>>> >>>> They do not "own" MaxDB. They license it, just like Innodb. >>> >>> >>> Damn, do they ever have alot of "loose ends" ... what part, exactly, >>> constitutes "MySQL" vs third party add ons? :) >> >> If MaxDB, InnoDB, and DBD engines are all licensed, then they have problems. > > Thank god our biggest headaches have been "can we include readline, since > its GPL?" and "we need to re-write ARC *just in case* IBM decides to > enforce their patent" :)" You mean "their eventually someday to be patent". Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I don't think that PostgreSQL is really on Oracle's radar at the moment. Please don't make this assumption. PostgreSQL is *very* much on their radar, and probably represents the biggest long-term threat to their core database business at the moment. We got a hint of that during the .org bidding, but for now it is in Oracle's interest not to call attention to PostgreSQL. The last thing they want is publicity for the project. We may be a harder target to hurt than MySQL, but we are a target, make no mistake about it. I'm sure PostgreSQL is on the radar of Sybase, Microsoft, and IBM as well. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200510170838 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iD8DBQFDU5wKvJuQZxSWSsgRAryKAKCkK1+4raUv0MOr/TaFOJoV6Vm9sACfXHDC fRH5+YBEVRQzih/yQYr6Su4= =AX08 -----END PGP SIGNATURE-----
> Please don't make this assumption. PostgreSQL is *very* much on their radar, > and probably represents the biggest long-term threat to their core database > business at the moment. We got a hint of that during the .org bidding, but > for now it is in Oracle's interest not to call attention to PostgreSQL. > The last thing they want is publicity for the project. We may be a harder > target to hurt than MySQL, but we are a target, make no mistake about it. > I'm sure PostgreSQL is on the radar of Sybase, Microsoft, and IBM as well. And they probably read every word we write ;) Chris
On Mon, 2005-10-17 at 09:46, Christopher Kings-Lynne wrote: > > Please don't make this assumption. PostgreSQL is *very* much on their radar, > > and probably represents the biggest long-term threat to their core database > > business at the moment. We got a hint of that during the .org bidding, but > > for now it is in Oracle's interest not to call attention to PostgreSQL. > > The last thing they want is publicity for the project. We may be a harder > > target to hurt than MySQL, but we are a target, make no mistake about it. > > I'm sure PostgreSQL is on the radar of Sybase, Microsoft, and IBM as well. > > And they probably read every word we write ;) I'd bet they read plenty, but don't necessarily understand a lot, judging by their pitiful fud campaign when Afilias proposed using postgresql as a database behind .org. They tried to say PostgreSQL didn't support transactions. So, while we may be on their screens, and I'm sure some marketeer there tries to keep up with some of the traffic here, the actual comprehension seems pretty low judging by their past statements. Actually, I kinda hope it stays that way.
On Mon, 2005-10-17 at 22:46 +0800, Christopher Kings-Lynne wrote: > And they probably read every word we write ;) ...and it will certainly slow them down :-)
tgl@sss.pgh.pa.us (Tom Lane) writes:
> I've been trying to figure out what it is that Oracle gets out of
> this, assuming that they don't see MySQL as a serious threat to
> their core business. The most they can do is force MySQL AB to
> waste a year or so reimplementing something equivalent to InnoDB;
> which would hurt them but it's hardly likely to kill them. But with
> your scenario Oracle might actually make money out of the deal,
> which makes it make some sense.
Well, Jan and I were puzzling over the whole "why MaxDB?" thing, and
the only way we were able to rationalize MySQL AB's involvement with
THAT was the theory that MySQL AB wants to become an alternative DB
backend vendor for SAP R/3.
Oracle is the main player there, and has been for a long time.
The whole thing about SAP AG buying up SAP-DB (which has become MaxDB)
was that they were "gaming" with Oracle over database licenses.
Having their own "free" alternative to Oracle represented a useful
tool when in license negotiations.
They then discovered that the codebase was something of a mess and
that they weren't interested in maintaining it, from whence came the
"freeing" of SAP-DB.
Where MySQL AB seems to fit into this is that they have a "barely
functional" DBMS engine that nonetheless happens to be nearly
functional enough to be usable as a backend for SAP R/3.
They were pretty proudly announcing at OSCON 2005 that they had enough
functionality to support R/3...
If MySQL AB has an *actively maintained* (unlike SAP-DB) database
engine, that makes them attractive to SAP AG whether as a business
partner or as a buyout target. Either could be quite attractive to
owners and venture capital providers alike.
Of course, if the "ability to support R/3" requires InnoDB stuff, then
this means Oracle just did a nice job of cutting off this strategy...
--
output = ("cbbrowne" "@" "cbbrowne.com")
http://cbbrowne.com/info/unix.html
Mental health is overrated!!
Scott Marlowe wrote: >I'd bet they read plenty, but don't necessarily understand a lot, >judging by their pitiful fud campaign when Afilias proposed using >postgresql as a database behind .org. They tried to say PostgreSQL >didn't support transactions. So, while we may be on their screens, and >I'm sure some marketeer there tries to keep up with some of the traffic >here, the actual comprehension seems pretty low judging by their past >statements. > >Actually, I kinda hope it stays that way. > > Ok. I should have said "serious target." MySQL has been a serious target for a number of years. I think we are still the unknown bugaboo to them. I.e. I see no evidence that Oracle is taking the PostgreSQL threat seriously, and the FUD campaign is more evidence that they don't (there are plenty of areas where Oracle has an edge over PostgreSQL-- the idea that "PostgreSQL doesn't support transactions" can only indicate that this was a cursory and hasty attack and maybe even a wakeup call for them, or maybe they got us mixed up with MySQL w/MyISAM). The real question is whether after the .org campaign occurred, we are now a higher-profile target that is taken more seriously. Personally, I would doubt it for reasons mentioned below. The thing is, we may be a head-to-head competitor with Oracle in many areas, but we are pretty minor compared to Sybase, Microsoft, and IBM at the moment. I.e. while we are an emerging threat, Oracle has plenty of clear and present threats to its market share to deal with. Therefore, I am willing to bet that we are probably a distant target, somewhere after Ingress II and maybe even Firebird/Interbase. This is based on the assumption that in any significantly large corporation, there will be a lot of legacy competitive effort and that the rampup time to look at new threats is really pretty large. I.e. at Microsoft when I left (2003), Java and Sun were still higher competitive priorities than Linux (and still very much in a middle-phase). From what I have read after leaving, I think that Microsoft's strategy is still in an opening phase mostly consisting of GetTheFUD and internal product research. MySQL is different. They established a large user base early on, and people have a tendency (wrongly) to think of them as The Open Source RDBMS. So I am willing to be that Oracle has been ramping up a competitive strategy against them for at least five years (they showed a clear competitive strategy against them as early as 2000). The fact that they are an easier target complicates matters for them, but I think that this is more of a transition to an end-game strategy by Oracle than anything else. I will be worried if and when Oracle demonstrates any intelligent competitive strategy against us. A poorly orchestrated and hasty FUD campaign does not qualify. Best Wishes, Chris Travers Metatron Technology Consulting
On Fri, Oct 14, 2005 at 02:28:52PM -0700, Joshua D. Drake wrote: > > > But what if they came in sideways and bought Command Prompt? > > Well then I would be sitting on a beach in New Zealend with an umbrella > drink :) > > > (As an > > example.) You could do a lot more to destroy PostgreSQL's market in the > > business world by destroying the various support mechanisms. Your > > business is much closer to eating their lunch than PostgreSQL itself. > > That is a farily good point but one of the beautiful things about Open > Source is that even if they bought Command Prompt, they would also have > to buy Pervasive and EnterpriseDB and GreenPlum and SRA. > > And then -- by doing so they are just opening the market for a new set > of companies to start supporting PostgreSQL. > > > So what if they bought Command Prompt (or someone else like it) and then > > cut it off at the knees? No one ever accused Larry Ellison of being > > dumb ... different strategies for different opponents. > > No, Larry isn't dumb. You don't get to be the second richest man in the > world by being dumb. However he is very strategic and I don't see (at > this point) a strategic reason to attack PostgreSQL via Oracle. > > PostgreSQL at this point is actually a good value add to the Oracle > proposition. In 5 years we are probably going to be a immediate direct > threat but not right now. > > Sincerely, > > Joshua D. Drake > > > > > > > Jeff > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 6: explain analyze is your friend > -- > Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 > PostgreSQL Replication, Consulting, Custom Programming, 24x7 support > Managed Services, Shared and Dedicated Hosting > Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ > The scenario that no one has mentioned wrt postgresql and oracle is that oracle can take the source code, branch it or not and support it. If they branch, it will have less credibility and it will become "interesting". But support money from a big name company (Oracle) should be forthcoming in either case. Long term that does not help the support companies, like mine and those mentioned above. Or maybe it does because we're smaller and faster. --elein -------------------------------------------------------------- elein@varlena.com Varlena, LLC www.varlena.com (510)655-2584(o) (510)543-6079(c) PostgreSQL Consulting, Support & Training PostgreSQL General Bits http://www.varlena.com/GeneralBits/ -------------------------------------------------------------- AIM: varlenallc Yahoo: AElein Skype: varlenallc -------------------------------------------------------------- I have always depended on the [QA] of strangers.
Chris Browne wrote: >tgl@sss.pgh.pa.us (Tom Lane) writes: > > >>I've been trying to figure out what it is that Oracle gets out of >>this, assuming that they don't see MySQL as a serious threat to >>their core business. The most they can do is force MySQL AB to >>waste a year or so reimplementing something equivalent to InnoDB; >>which would hurt them but it's hardly likely to kill them. But with >>your scenario Oracle might actually make money out of the deal, >>which makes it make some sense. >> >> > >Well, Jan and I were puzzling over the whole "why MaxDB?" thing, and >the only way we were able to rationalize MySQL AB's involvement with >THAT was the theory that MySQL AB wants to become an alternative DB >backend vendor for SAP R/3. > >Oracle is the main player there, and has been for a long time. > >The whole thing about SAP AG buying up SAP-DB (which has become MaxDB) >was that they were "gaming" with Oracle over database licenses. >Having their own "free" alternative to Oracle represented a useful >tool when in license negotiations. > > Interesting thought. It also explains Oracle's additional market pressure against MySQL AB.... >Where MySQL AB seems to fit into this is that they have a "barely >functional" DBMS engine that nonetheless happens to be nearly >functional enough to be usable as a backend for SAP R/3. > >They were pretty proudly announcing at OSCON 2005 that they had enough >functionality to support R/3... > > Was this MaxDB or MySQL? >If MySQL AB has an *actively maintained* (unlike SAP-DB) database >engine, that makes them attractive to SAP AG whether as a business >partner or as a buyout target. Either could be quite attractive to >owners and venture capital providers alike. > >Of course, if the "ability to support R/3" requires InnoDB stuff, then >this means Oracle just did a nice job of cutting off this strategy... > > Even if it doesn't require InnoDB... Cast a long enough shadow on MySQL AB and that active maintenance of MaxDB will be harder to justify. I.e. death by asphyxiation will kill any project or company. My predictions are that Oracle will try to drive up the costs of MySQL and then when the company starts to flounder, will buy it for pennies on the dollar. If they are actively maintaining MaxDB, well, this just cut the knees out from under that. Also, what Oracle has done is cast enough of a shadow on MySQL to make them a very unattractive buyout target. This is a very interesting move by Oracle... It will be interesting to see where it goes.... Best Wishes, Chris Travers Metatron Technology Consulting
On Mon, Oct 17, 2005 at 11:20:00AM -0700, elein wrote: > The scenario that no one has mentioned wrt postgresql and oracle is > that oracle can take the source code, branch it or not and support it. > If they branch, it will have less credibility and it will become "interesting". > But support money from a big name company (Oracle) should be > forthcoming in either case. > > Long term that does not help the support companies, like mine and those > mentioned above. Or maybe it does because we're smaller and faster. I suspect that if Oracle were to actually formally endorse PostgreSQL by offering support that people would be falling all over themselves to find out what "this PostgreSQL thing" was all about. It would probably be a win for everyone already doing work with PostgreSQL; existing customers probably wouldn't be motivated enough to change support providers just because it's Oracle, and meanwhile many people would look to see who else was offering Oracle support. Of course, Oracle could tank the market by offering support at un-competitive prices, but I can't think of a reason for them to do that off the top of my head. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
Chris Browne <cbbrowne@acm.org> writes:
> tgl@sss.pgh.pa.us (Tom Lane) writes:
>> I've been trying to figure out what it is that Oracle gets out of
>> this, assuming that they don't see MySQL as a serious threat to
>> their core business.
> [ snip ]
> Of course, if the "ability to support R/3" requires InnoDB stuff, then
> this means Oracle just did a nice job of cutting off this strategy...
Ah-hah. *Now* it's all clear: an alternative to Oracle for SAP would
definitely be a strong threat to Oracle's bottom line. I think we just
found the real motivation.
(BTW, has anyone looked lately to see how far away Postgres is from
being able to run SAP?)
regards, tom lane
"Jim C. Nasby" <jnasby@pervasive.com> writes:
> Of course, Oracle could tank the market by offering support at
> un-competitive prices, but I can't think of a reason for them to do that
> off the top of my head.
They might hope that they could drive the existing support companies out
of business (assuming they didn't get convicted of antitrust violations
first --- which would be an open-and-shut case, but with the Republicans
in office they probably wouldn't get prosecuted :-(). Then they raise
their rates to make lotsa money, or maybe they'd think they could drop
support at that point and the project would die for lack of commercial
support. (They seem to understand open-source poorly enough that they
might think that would happen.)
I don't see any of this happening though. As suggested upthread,
the very *last* thing Oracle wants is to raise the visibility and
credibility of Postgres by a couple of orders of magnitude --- which
is exactly what they'd be doing by offering support for it, even if
the support was only temporary. The effects of getting the word out
would persist long afterwards.
regards, tom lane
elein wrote: > >The scenario that no one has mentioned wrt postgresql and oracle is >that oracle can take the source code, branch it or not and support it. >If they branch, it will have less credibility and it will become "interesting". >But support money from a big name company (Oracle) should be >forthcoming in either case. > >Long term that does not help the support companies, like mine and those >mentioned above. Or maybe it does because we're smaller and faster. > > It could work both ways. I am sure that if that happened, that Oracle would be contributing to the PostgreSQL code base in some ways. However, this would be somewhat bad for them because they would be commoditizing their flagship product, but Oracle is mostly a services business and would probably be able to make the transition relatively well. The bigger deal would be for companies like EnterpriseDB. OTOH, would you rather deal with the likes of Larry Ellison and his peons or the likes of you, Josh (both of them), etc? I think Oracle will start marketing PostgreSQL sometime after IBM jumps on ship. But don't expect either soon. Best Wishes, Chris Travers Metatron Technology Consulting
Tom Lane wrote: > Chris Browne <cbbrowne@acm.org> writes: >> Of course, if the "ability to support R/3" ... > Ah-hah. *Now* it's all clear: an alternative to Oracle for SAP... Speaking of SAP... Jeff Nolan, a Venture Capitalists from SAP Ventures (http://www.sap.com/company/sapventures/contacts/index.epx) has been following the Oracle/Innobase acquisition, and has some rumors and speculation around the events. For one, he's heard $5-$6 million and that MySQL has some guarantees on their Innobase contract: http://sapventures.typepad.com/main/2005/10/how_much_did_or.html and had some speculation of petty bickering between Benchmark (the lead VC in MySQL's previous round) and a partner from Oracle (Lane) at a rival firm: http://sapventures.typepad.com/main/2005/10/innobase_ray_la.html Marten Mickos himself responded and denied that rumor, and he later retracted that speculation.
Tom Lane wrote: > (BTW, has anyone looked lately to see how far away Postgres is from > being able to run SAP?) It runs OpenMFG just fine ;-)
tgl@sss.pgh.pa.us (Tom Lane) writes: > Chris Browne <cbbrowne@acm.org> writes: >> tgl@sss.pgh.pa.us (Tom Lane) writes: >>> I've been trying to figure out what it is that Oracle gets out of >>> this, assuming that they don't see MySQL as a serious threat to >>> their core business. > >> [ snip ] > >> Of course, if the "ability to support R/3" requires InnoDB stuff, then >> this means Oracle just did a nice job of cutting off this strategy... > > Ah-hah. *Now* it's all clear: an alternative to Oracle for SAP would > definitely be a strong threat to Oracle's bottom line. I think we just > found the real motivation. > > (BTW, has anyone looked lately to see how far away Postgres is from > being able to run SAP?) I'd think that the main issue is that of attracting interest from SAP AG to do a port. They don't require triggers, RI, stored procedures, nor, if I recall, views. Sybase was long NOT supportable due to it not having row locks, but rather only page locks. That drove functionality added to Microsoft SQL Server back in the late '90s. It's _possible_ that MVCC could cause some heartburn, though since Oracle and DB2 both have added forms of this, I kind of doubt it. I don't expect that Postgres is missing anything of importance aside from there being a "champion" with budgetary discretion for the $8M task of preparing a port. R/3 has fairly separate "kernels" for each DBMS that it supports, and that's not a small thing. It's _not_ like in the late '90s where internal developers had "skunkworks" ports of Oracle/Informix/DB2 to Linux where they were able to report "Oh, we compiled it one weekend and it found that it just simply works." Porting the R/3 kernel to another DBMS would involve things akin to: - Coding an internal layer that knows to talk to libpq - Knowing the different ways of handling R/3 weirdities like cluster tables (where I'd bet money that DEFINE TYPE would make life easier in a PostgreSQL port...) - Awareness of the variations in locking semantics and such The kernel is a real heavyweight, so a port would require quite a lot of effort. -- (format nil "~S@~S" "cbbrowne" "ntlug.org") http://cbbrowne.com/info/linuxdistributions.html "The test of a principle is whether it applies even to people you don't like." -- Henry Spencer
pgsql-general-owner@postgresql.org wrote on 10/17/2005 01:44:24 PM: <snip> > > (BTW, has anyone looked lately to see how far away Postgres is from > being able to run SAP?) Uh, Tom? Are you in the habit of waiving red capes in front of bulls? :) I assume the question was rhetorical, due to MySQL's capability gap with PostgreSQL. > > 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
Tom Lane wrote: > > >They might hope that they could drive the existing support companies out >of business (assuming they didn't get convicted of antitrust violations >first --- which would be an open-and-shut case, but with the Republicans >in office they probably wouldn't get prosecuted :-(). > Sort of off-topic but after actually reading up on notable antitrust cases (such as AT&T), I think that the current situation wrt Microsoft is exactly how antitrust law works best in our legal system. And anyone who thinks that Microsoft effectively put this behind them has not been following Novell v. Microsoft and a myriad of other cases. Because Microsoft has lost their case, certain facts cannot be litigated, meaning that it is now open season on suing Microsoft for antitrust violations.... (IANAL, but you can ask one about "collateral estoppel" which is a really nasty ball of wax for Microsoft at the moment). The current settlement really was forced on the DoJ by the appeals court. This is one area where Microsoft would have been better off (and we might be worse off) had they been broken up. For example, AMD faces a much harder antitrust case against Intel than Novel does against Microsoft for the reason that Intel has settled all previous antitrust cases without admitting guilt. Don't think so? Why do you think Microsoft settled IBM's antitrust claims before the lawsuit was even filed (normally people at least go through pretrial motions to see how much of the complaint they can get dropped before settling)? Indeed I have personally wondered if Microsoft opened themselves up to more lawsuits by recommending that Baystar invest in SCO.... As for Oracle, they don't exactly have a steller reputation. However, they hopefully have enough to sense to avoid antitrust cases they could lose. At least in the past, their prior questionable actions have been of generally unfair business practices such as industrial espionage (didn't they hire the firm that got the janatorial contract at Microsoft to do dumpster-diving for them in 1999 or so). But the biggest issue for them is that other parties (such as IBM and Microsoft) have been making substantial inroads into Oracle's core market. Spend too much in the way of resources attacking us and they divert resources from the clear dangers that they have from large commercial competitors. > Then they raise >their rates to make lotsa money, or maybe they'd think they could drop >support at that point and the project would die for lack of commercial >support. (They seem to understand open-source poorly enough that they >might think that would happen.) > > Who knows? Maybe they will resort to dumpster-diving to try to discover our super-secret-source-code... ;-) >I don't see any of this happening though. As suggested upthread, >the very *last* thing Oracle wants is to raise the visibility and >credibility of Postgres by a couple of orders of magnitude --- which >is exactly what they'd be doing by offering support for it, even if >the support was only temporary. The effects of getting the word out >would persist long afterwards. > > I would suggest that Oracle has not formed a strategy for outcompeting us yet, and it may be several years before they take the threat we pose seriously enough to really start work on it. I would suspect that we are treated as "one of a crowd of mid-size RDBMS competitors," and have not been singled out yet for special treatment (MySQL was singled out in 2000 at the latest). Oracle's current strategy seems to be in trying to push things like parallel queries, grid computing, etc. as a way of providing scalability and room for growth, providing advantages for certain scenarios. They could then use the high-end to subsidize the low end, like Sun does with Solaris (though I think that this is a losing strategy and Microsoft's inverse strategy of subsidizing the high-end with the commodity market is ultimately more effective). Maybe when Bizgres MPP comes out things will change ;-) Best Wishes, Chris Travers
On Mon, Oct 17, 2005 at 11:18:19AM -0700, Chris Travers wrote: > I.e. I see no evidence that Oracle is taking the PostgreSQL threat > seriously, and the FUD campaign is more evidence that they don't (there > are plenty of areas where Oracle has an edge over PostgreSQL-- the idea > that "PostgreSQL doesn't support transactions" can only indicate that > this was a cursory and hasty attack and maybe even a wakeup call for > them, or maybe they got us mixed up with MySQL w/MyISAM). The real > question is whether after the .org campaign occurred, we are now a > higher-profile target that is taken more seriously. Personally, I would > doubt it for reasons mentioned below. (I'm using this as an example of more than one such comment in this thread). The claim in the .org bid response (which can be found at <http://forum.icann.org/org-eval/gartner-report/msg00000.html>) starts like this: PostgreSQL, like many other open source database products, has been in the market for many years with very little adoption. Unlike the open-source operating system market, the open-source database market has been unsuccessful due to the complexity of customer requirements and sophistication of the technology needed. PostgreSQL is used primarily in the embedded system market because it lacks the transactional features, high availability, security and manageability of any commercial enterprise database. Note the slide at the beginning of that from "PostgreSQL" to "open source database products". That trick is consistent with several other things I've seen from Oracle, including Ellison, on this topic. The idea is to lump everything into the "open source" class, and then attack the technically weakest member of that class. It's good rhetoric, so I don't think anyone should believe, for a second, that this is some kind of know-nothing answer from Oracle. It's a good strategy. I'll also note that I've spoken to people inside IBM's DB2 division who have, as part of their job, keeping tabs on PostgreSQL. This is why I think we should avoid worrying about MySQL: it gives others an opportunity to lump us into the "open source" pile, and dismiss the whole thing on the basis of the missing features in MySQL. A -- Andrew Sullivan | ajs@crankycanuck.ca When my information changes, I alter my conclusions. What do you do sir? --attr. John Maynard Keynes
On Tue, Oct 18, 2005 at 01:19:53PM -0700, Chris Travers wrote:
> Ok. but it is still a lazy approach and indicates that Oracle has not
> singled us out for special treatment. Again, this was not the case with
> MySQL as of 2000 at the latest.
I may be more paranoid, but that may be because our use of PostgreSQL
was real unpopular in the original Oracle shop where the registry
software was developed (the technical side of Afilias was originally
called Liberty RMS, and was a subsidiary of TUCOWS. I was hired
originally by them. Afilias bought Liberty not long after the .info
registry went live, however, and we've always been a better fit here
than we were at TUCOWS). I do know, however, that Oracle doesn't
publicly talk about PostgreSQL, but they have plenty to say in
private about it to their existing customers. And it's not nearly as
ill-informed as the public comments suggest.
> I think it is important to eventually capture the image of PostgreSQL as
> *the* FOSS RDBMS (which MySQL currently still holds among too many
> developers). But that is the extent of my concern with them.
Sure. But if you build a reputation as an industrial-strength system
that happens to be free, you can go after the FOSS area without much
additional effort; whereas if you concentrate first on being free,
you then have the later problem of moving from "free" to "enterprise
grade".
A
--
Andrew Sullivan | ajs@crankycanuck.ca
Information security isn't a technological problem. It's an economics
problem.
--Bruce Schneier
Andrew Sullivan wrote: > Note the slide at the beginning of that from "PostgreSQL" to "open > >source database products". That trick is consistent with several >other things I've seen from Oracle, including Ellison, on this topic. >The idea is to lump everything into the "open source" class, and then >attack the technically weakest member of that class. It's good >rhetoric, so I don't think anyone should believe, for a second, that >this is some kind of know-nothing answer from Oracle. It's a good >strategy. > > Ok. but it is still a lazy approach and indicates that Oracle has not singled us out for special treatment. Again, this was not the case with MySQL as of 2000 at the latest. >I'll also note that I've spoken to people inside IBM's DB2 division >who have, as part of their job, keeping tabs on PostgreSQL. > > I am sure of that. I *do* see evidence that IBM has singled PostgreSQL out for special treatment. Their attacks are much better informed than those of Oracle and tend to the specific case study of Sourceforge. This is not the "lump all FOSS RDBMS's together" or even "lump all mid-range competitors together with lower end RDBMS's and attack them as a group" strategy that they seem to be applying here. That is also part of the reason why I predict that IBM will start marketing PostgreSQL before Oracle does ;-) But this may be a few years off.... This being said.... I see very little evidence that PostgreSQL is mostly deployed in the embedded device market. And while it is true that there are a few transactional features (such as savepoints) that were missing as of 2002, these were fairly minor and usually limited to very complex applications (and reasonable to code around in most but not all cases). >This is why I think we should avoid worrying about MySQL: it gives >others an opportunity to lump us into the "open source" pile, and >dismiss the whole thing on the basis of the missing features in >MySQL. > I think it is important to eventually capture the image of PostgreSQL as *the* FOSS RDBMS (which MySQL currently still holds among too many developers). But that is the extent of my concern with them. Best Wishes, Chris Travers Metatron Technology Consulting
Andrew Sullivan wrote: >On Tue, Oct 18, 2005 at 01:19:53PM -0700, Chris Travers wrote: > > >>Ok. but it is still a lazy approach and indicates that Oracle has not >>singled us out for special treatment. Again, this was not the case with >>MySQL as of 2000 at the latest. >> >> > >I may be more paranoid, but that may be because our use of PostgreSQL >was real unpopular in the original Oracle shop where the registry >software was developed (the technical side of Afilias was originally >called Liberty RMS, and was a subsidiary of TUCOWS. I was hired >originally by them. Afilias bought Liberty not long after the .info >registry went live, however, and we've always been a better fit here >than we were at TUCOWS). I do know, however, that Oracle doesn't >publicly talk about PostgreSQL, but they have plenty to say in >private about it to their existing customers. And it's not nearly as >ill-informed as the public comments suggest. > > Interesting. So they are willing to appear ill-informed in public but better informed in private? To what end? That seems strange to me.... > > >>I think it is important to eventually capture the image of PostgreSQL as >>*the* FOSS RDBMS (which MySQL currently still holds among too many >>developers). But that is the extent of my concern with them. >> >> > >Sure. But if you build a reputation as an industrial-strength system >that happens to be free, you can go after the FOSS area without much >additional effort; whereas if you concentrate first on being free, >you then have the later problem of moving from "free" to "enterprise >grade". > > Well, it cuts both ways. MySQL's strategy is very Microsoft-like (in an effective way) in that it seeks to use the commodity market to subsidize the higher end-market and thereby grow its way into the enterprise, sort of like Windows.... This really isn't a bad way to go. However, where we shine is that we have a bigger and more active community than MySQL (to the extent that MySQL used to criticize us for it). This is in the end what really matters in the short run. However, failing to capture the low-end market (including uninteresting markets like CMS, low-end web apps, etc) has a number of real disadvantages including: 1) Beginners learn bad habits via MySQL and MS Access. 2) Those beginners may grow to do larger applications and will try to use MS Access or MySQL in ways that it is not designed to work (and for MS Access users, they will invariably go to MS SQL). This is one reason why I would like to see some of us push PostgreSQL into a role of *the* RDBMS to study for RDBMS theory. Unfortunately this means a lot of documentation written by experts interested in really teaching beginners the right way to do things.... I don't consider myself qualified to do this by myself. Best Wishes, Chris Travers Metatron Technology Consulting
Attachment
On Monday 17 October 2005 13:01, Scott Marlowe wrote:
> On Mon, 2005-10-17 at 09:46, Christopher Kings-Lynne wrote:
> > > Please don't make this assumption. PostgreSQL is *very* much on their
> > > radar, and probably represents the biggest long-term threat to their
> > > core database business at the moment. We got a hint of that during the
> > > .org bidding, but for now it is in Oracle's interest not to call
> > > attention to PostgreSQL. The last thing they want is publicity for the
> > > project. We may be a harder target to hurt than MySQL, but we are a
> > > target, make no mistake about it. I'm sure PostgreSQL is on the radar
> > > of Sybase, Microsoft, and IBM as well.
> >
> > And they probably read every word we write ;)
>
> I'd bet they read plenty, but don't necessarily understand a lot,
> judging by their pitiful fud campaign when Afilias proposed using
> postgresql as a database behind .org. They tried to say PostgreSQL
> didn't support transactions. So, while we may be on their screens, and
> I'm sure some marketeer there tries to keep up with some of the traffic
> here, the actual comprehension seems pretty low judging by their past
> statements.
>
> Actually, I kinda hope it stays that way.
>
Don't bet on it. If Afilias is 4 years smarter about postgresql, you can bet
Oracle is too. In fact my guess is that they started reading up as soon
as .org was awarded to a pg based company. I think before that they
probably figured that my$ql, being more popular, was roughly equal if not
better than postgresql, and often confused the two. If there smart enough to
be buying innobase these days, you can bet that by now they have this stuff
all straightened out.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Robert Treat <xzilla@users.sourceforge.net> writes:
> If there smart enough to
> be buying innobase these days, you can bet that by now they have this stuff
> all straightened out.
No, that doesn't seem to follow ... if Oracle are spending their
resources to attack MySQL rather than us, the conclusion would be that
they are clearly still more informed by "the buzz" than technical merit.
What seems likely to me is that the Innobase purchase was a target
of opportunity --- they saw a chance to destroy a potential threat,
and took it. This proves nothing about their assessment of the
relative risks from us and MySQL ... only that they haven't yet
thought of an equally painless way to destroy us.
regards, tom lane
>>If there smart enough to >>be buying innobase these days, you can bet that by now they have this stuff >>all straightened out. > > > No, that doesn't seem to follow ... if Oracle are spending their > resources to attack MySQL rather than us, the conclusion would be that > they are clearly still more informed by "the buzz" than technical merit. With no disrespect to PostgreSQL, MySQL has 100x our downloads and installations... Oracle is simply going after by far the biggest open source database player... Chris
Christopher Kings-Lynne wrote: > With no disrespect to PostgreSQL, MySQL has 100x our downloads and > installations... > > Oracle is simply going after by far the biggest open source database > player... > As I said, Oracle demonstrated in 2000 that they had already singled MySQL out for special competitive treatement. They did this by starting to offer db conversion utilities in order to help people migrate from MySQL to Oracle. It is not about technical merit, it is about market share. We could have the best RDBMS in the world but if we never get enough users to directly threaten them to the level that MS SQL Server or DB2 does, we are not the threat that they are, and we are not worth the time and expense that research, competitive strategizing, etc. would incur. Therefore, I suspect that we are sort of on the back burner competitive strategy wise. I.e. competition is on a project-by-project basis, and not coordinated as of yet. There are some things on the horizon that could change this quite quickly, however: 1) Sun is talking about packaging PostgreSQL and distributing it with Solaris. This would bring us directly head to head with Oracle in a large number of potential installations. 2) EnterpriseDB's efforts and awards may have attracted some attention. This may reinforce the idea that we are a threat. If this is the case, I bet that Oracle is probably pressuring Sun not to distribute PostgreSQL, and if they do anyway, we need to be concerned about the beginning of a high-level coordinated strategy targetting us specifically. IMO, it is likely to start with one of two things: 1) PostgreSQL to Oracle database conversion utilities released by Oracle (unlikely given extensible languages in PostgreSQL). 2) Some sort of FUD campaign on the part of Oracle directed specifically at us and not tied to any specific project (fairly likely). Best Wishes, Chris Travers Metatron Technology Consulting
Attachment
On Tuesday 18 October 2005 23:44, Chris Travers wrote:
> Christopher Kings-Lynne wrote:
> > With no disrespect to PostgreSQL, MySQL has 100x our downloads and
> > installations...
> >
> > Oracle is simply going after by far the biggest open source database
> > player...
>
> As I said, Oracle demonstrated in 2000 that they had already singled
> MySQL out for special competitive treatement. They did this by starting
> to offer db conversion utilities in order to help people migrate from
> MySQL to Oracle. It is not about technical merit, it is about market
> share. We could have the best RDBMS in the world but if we never get
wadda ya mean "could"?" :-)
> enough users to directly threaten them to the level that MS SQL Server
> or DB2 does, we are not the threat that they are, and we are not worth
> the time and expense that research, competitive strategizing, etc. would
> incur. Therefore, I suspect that we are sort of on the back burner
> competitive strategy wise. I.e. competition is on a project-by-project
> basis, and not coordinated as of yet.
>
> There are some things on the horizon that could change this quite
> quickly, however:
>
> 1) Sun is talking about packaging PostgreSQL and distributing it with
> Solaris. This would bring us directly head to head with Oracle in a
> large number of potential installations.
>
> 2) EnterpriseDB's efforts and awards may have attracted some
> attention. This may reinforce the idea that we are a threat.
>
> If this is the case, I bet that Oracle is probably pressuring Sun not to
> distribute PostgreSQL, and if they do anyway, we need to be concerned
> about the beginning of a high-level coordinated strategy targetting us
> specifically. IMO, it is likely to start with one of two things:
>
> 1) PostgreSQL to Oracle database conversion utilities released by
> Oracle (unlikely given extensible languages in PostgreSQL).
they need to "reverse" engineer enterprisedb :-)
> 2) Some sort of FUD campaign on the part of Oracle directed
> specifically at us and not tied to any specific project (fairly likely).
>
look for pointers to lack of benchmarks, patent issues, and great bridge...
those seem to be the most common rehash of fud.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Chris Travers <chris@verkiel.metatrontech.com> writes:
> IMO, it is likely to start with one of two things:
> 1) PostgreSQL to Oracle database conversion utilities released by
> Oracle (unlikely given extensible languages in PostgreSQL).
> 2) Some sort of FUD campaign on the part of Oracle directed
> specifically at us and not tied to any specific project (fairly likely).
Well, #1 would require quite a nontrivial investment of time by Oracle
(I doubt they'd even think about offering ports of any PL other than
plpgsql, and still it'd be a major project). #2 only requires inventing
some plausible lies. So you can bet we'll see #2 long before #1.
As Andrew noted, we've already heard plenty of FUD from Oracle. What
we've not seen is a FUD campaign based on serious study of our
weaknesses --- they've only bothered to muster transparent attacks on
"open source DBs" in general. My prediction is that the next step will
be FUD that's really designed specifically against Postgres.
regards, tom lane
> 1) PostgreSQL to Oracle database conversion utilities released by > Oracle (unlikely given extensible languages in PostgreSQL). Strangely a pgsql to oracle exporter is a good thing. It'd be a great feature of PostgreSQL. Imagine how many people would start on PostgreSQL if they KNEW that one day they could easily move to Oracle if they needed to. Risk management. Chris
> As Andrew noted, we've already heard plenty of FUD from Oracle. What > we've not seen is a FUD campaign based on serious study of our > weaknesses --- they've only bothered to muster transparent attacks on > "open source DBs" in general. My prediction is that the next step will > be FUD that's really designed specifically against Postgres. I admit I must have missed all this '.org FUD' - is it still around. I really don't know what you guys are referring to. Chris
Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
> Strangely a pgsql to oracle exporter is a good thing. It'd be a great
> feature of PostgreSQL. Imagine how many people would start on
> PostgreSQL if they KNEW that one day they could easily move to Oracle if
> they needed to. Risk management.
Problem is: to offer such a thing with a straight face, we'd have to
confine ourselves to an Oracle-subset version of SQL. For instance,
lose the ability to distinguish empty-string from NULL.
regards, tom lane
> Problem is: to offer such a thing with a straight face, we'd have to > confine ourselves to an Oracle-subset version of SQL. For instance, > lose the ability to distinguish empty-string from NULL. I wasn't saying we write it - let Oracle do it :D Chris
On Wed, 19 Oct 2005, Christopher Kings-Lynne wrote:
>>> If there smart enough to be buying innobase these days, you can bet that
>>> by now they have this stuff all straightened out.
>>
>>
>> No, that doesn't seem to follow ... if Oracle are spending their
>> resources to attack MySQL rather than us, the conclusion would be that
>> they are clearly still more informed by "the buzz" than technical merit.
>
> With no disrespect to PostgreSQL, MySQL has 100x our downloads and
> installations...
Yeah, kids playing with toys. You can't imagine how many people I heard
have MySQL installed in there win98.
The bad thing is they addopt MySQL because they could have it installed
there. :-(
--
11:55:01 up 155 days, 1:49, 3 users, load average: 0.12, 0.72, 0.86
-----------------------------------------------------------------
Lic. Martín Marqués | select 'mmarques' || '@' || 'unl.edu.ar'
Centro de Telematica | DBA, Programador, Administrador
Universidad Nacional
del Litoral
-----------------------------------------------------------------
On Wed, Oct 19, 2005 at 10:55:22AM +0800, Christopher Kings-Lynne wrote: > With no disrespect to PostgreSQL, MySQL has 100x our downloads and > installations... Just for the hell of it I looked at the popcon stats for debian installs (see below). It tells me the following: - Something like half the people who install mysql-server (any version) never use it. People who install PostgreSQL are (slightly) more likely to actually use it. - For mysql, users of the client are approximatly twice the amount that use the server. For postgres, the client and server count is about the same. This one is curious, don't know what to make of it. - when it comes to client libs, a lot of people have them installed (presumably linked to various apps) but they don't apparently connect anywhere with them. Now, this is not exactly a represenative sample and statistical errors abound, and we're not counting Windows installations but 100x seems like an exaggeration to me... :) Have a nice day, #<name> is the package name; #<inst> is the number of people who installed this package; #<vote> is the number of people who use this package regularly; #<old> is the number of people who installed, but don't use this package # regularly; #<recent> is the number of people who upgraded this package recently; #<no-files> is the number of people whose entry didn't contain enough # information (atime and ctime were 0). #rank name inst vote old recent no-files (maintainer) 183 libmysqlclient12 4483 3026 663 421 373 (Christian Hammers) 266 mysql-client 2803 2188 216 172 227 (Christian Hammers) 453 libpq3 3710 1266 1065 231 1148 (Martin Pitt) 478 mysql-server 2342 1171 529 490 152 (Christian Hammers) 553 libmysqlclient14 2437 954 145 332 1006 (Christian Hammers) 583 mysql-client-4.1 1111 886 21 204 0 (Christian Hammers) 661 postgresql-client 1709 729 372 31 577 (Martin Pitt) 662 postgresql 1286 728 132 14 412 (Martin Pitt) 883 mysql-server-4.1 883 490 84 309 0 (Christian Hammers) 1202 postgresql-7.4 468 308 37 123 0 (Martin Pitt) 1531 libmysqlclient10 3277 214 518 48 2497 (Steve Langasek) 2253 postgresql-client-8.0 185 110 16 59 0 (Martin Pitt) 2261 postgresql-8.0 172 109 17 46 0 (Martin Pitt) 2332 mysql-client-5.0 120 102 1 17 0 (Christian Hammers) 2757 mysql-server-5.0 113 77 3 33 0 (Christian Hammers) -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
Attachment
On Wed, 2005-10-19 at 12:51 +0200, Martijn van Oosterhout wrote: > Just for the hell of it I looked at the popcon stats for debian > installs (see below). It tells me the following: > > - Something like half the people who install mysql-server (any version) > never use it. People who install PostgreSQL are (slightly) more likely > to actually use it. > > - For mysql, users of the client are approximatly twice the amount that > use the server. For postgres, the client and server count is about the > same. This one is curious, don't know what to make of it. When you install Debian from scratch, the tasksel list offers you the chance to install database packages. If you select that, it installs postgresql server rather than mysql, which may help the statistics in Debian. The postgresql server package depends on postgresql-client. I think that the only people to install postgresql-client without the server would be those with multiple machines communicating with a server and a number of those might install the server by mistake. The ratio of nearly 6 to 4 seems quite reasonable. -- Oliver Elphick olly@lfix.co.uk Isle of Wight http://www.lfix.co.uk/oliver GPG: 1024D/A54310EA 92C8 39E7 280E 3631 3F0E 1EC0 5664 7A2F A543 10EA ======================================== Do you want to know God? http://www.lfix.co.uk/knowing_god.html
Tom Lane wrote: > Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes: > >>Strangely a pgsql to oracle exporter is a good thing. It'd be a great >>feature of PostgreSQL. Imagine how many people would start on >>PostgreSQL if they KNEW that one day they could easily move to Oracle if >>they needed to. Risk management. > > > Problem is: to offer such a thing with a straight face, we'd have to > confine ourselves to an Oracle-subset version of SQL. For instance, > lose the ability to distinguish empty-string from NULL. Oh please PLEASE *PLEASE* don't bend that way. Oracle has some SQL non compliant flaws at least one is serious: The inability to distinguish between the absence of value and an explicitly empty string is just ONE of Oracle's ridiculous fubarness. People who know what a NULL really is and use it properly have to program around Oracle's stupidity to "dumb it down" for the weak application developer, let's not do that. Terry > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings > -- Terry Fielder terry@greatgulfhomes.com Associate Director Software Development and Deployment Great Gulf Homes / Ashton Woods Homes Fax: (416) 441-9085
I think this probably belongs back on -advocacy, so I'm cc:ing there
so we can move it.
On Tue, Oct 18, 2005 at 03:16:23PM -0700, Chris Travers wrote:
> Interesting. So they are willing to appear ill-informed in public but
> better informed in private? To what end? That seems strange to me....
To the end of dismissing the serious-but-free competition in public.
If Oracle is talking to the computer press, they have enough
experience to know just how much they can play with stating the way
the world is, and have it quoted verbatim as revealed truth. Apart
from database weenies like us, people reading the Oracle
pronouncement conflating PostgreSQL and other database systems will
just think it's true. After all, Oracle said it, and the press guy
from InfoWorld must have checked it out, right? If you think I'm
being unduly cynical, note that the Gartner comments in their
consulting for ICANN in the .org reassignment basically argued that
PostgreSQL was a significant risk because it wasn't Oracle. There's
nothing _wrong_ with that way of thinking -- corporations are mostly
about stability, which means following conventional (==safe) wisdom.
But that mindset is something that Oracle is skilled at exploiting,
and I'm not surprised they do it against PostgreSQL (even if their
behaviour sounds irrational to someone who really knows the
capabilities of the various systems).
But that isn't really why I replied to this :)
> This is one reason why I would like to see some of us push PostgreSQL
> into a role of *the* RDBMS to study for RDBMS theory. Unfortunately
> this means a lot of documentation written by experts interested in
> really teaching beginners the right way to do things.... I don't
> consider myself qualified to do this by myself.
I like this idea. I wonder how to get it moving.
A
--
Andrew Sullivan | ajs@crankycanuck.ca
"The year's penultimate month" is not in truth a good way of saying
November.
--H.W. Fowler
pgsql-general-owner@postgresql.org wrote on 10/19/2005 12:35:25 AM: > Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes: > > Strangely a pgsql to oracle exporter is a good thing. It'd be a great > > feature of PostgreSQL. Imagine how many people would start on > > PostgreSQL if they KNEW that one day they could easily move to Oracle if > > they needed to. Risk management. > > Problem is: to offer such a thing with a straight face, we'd have to > confine ourselves to an Oracle-subset version of SQL. For instance, > lose the ability to distinguish empty-string from NULL. Yep. It is not just limited to empty strings; An all blank string, no matter the number of characters, is stored as NULL. And a corollary to that idiocy is that a string with two blank characters is not equal to a string with a single blank character in Oracle. 'a ' is not equal to 'a '. 'a ' is not equal to 'a'. Port that to another database. Seen the JOIN syntax? *sigh* Rick > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings
On Wed, 19 Oct 2005, Richard_D_Levine@raytheon.com wrote: > > > pgsql-general-owner@postgresql.org wrote on 10/19/2005 12:35:25 AM: > >> Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes: >>> Strangely a pgsql to oracle exporter is a good thing. It'd be a great >>> feature of PostgreSQL. Imagine how many people would start on >>> PostgreSQL if they KNEW that one day they could easily move to Oracle > if >>> they needed to. Risk management. >> >> Problem is: to offer such a thing with a straight face, we'd have to >> confine ourselves to an Oracle-subset version of SQL. For instance, >> lose the ability to distinguish empty-string from NULL. > > Yep. It is not just limited to empty strings; An all blank string, no > matter the number of characters, is stored as NULL. And a corollary to > that idiocy is that a string with two blank characters is not equal to a > string with a single blank character in Oracle. 'a ' is not equal to 'a > '. 'a ' is not equal to 'a'. Port that to another database. Seen the > JOIN syntax? *sigh* Wait, I've lost something here, apparently ... but that is the case with PostgreSQL as well: ams=# select ' a' = ' a'; ?column? ---------- f (1 row) Let me guess ... MySQL treats them as equal?? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
"Marc G. Fournier" <scrappy@postgresql.org> wrote on 10/19/2005 01:02:15 PM: > On Wed, 19 Oct 2005, Richard_D_Levine@raytheon.com wrote: > > > > > > > pgsql-general-owner@postgresql.org wrote on 10/19/2005 12:35:25 AM: > > > >> Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes: > >>> Strangely a pgsql to oracle exporter is a good thing. It'd be a great > >>> feature of PostgreSQL. Imagine how many people would start on > >>> PostgreSQL if they KNEW that one day they could easily move to Oracle > > if > >>> they needed to. Risk management. > >> > >> Problem is: to offer such a thing with a straight face, we'd have to > >> confine ourselves to an Oracle-subset version of SQL. For instance, > >> lose the ability to distinguish empty-string from NULL. > > > > Yep. It is not just limited to empty strings; An all blank string, no > > matter the number of characters, is stored as NULL. And a corollary to > > that idiocy is that a string with two blank characters is not equal to a > > string with a single blank character in Oracle. 'a ' is not equal to 'a > > '. 'a ' is not equal to 'a'. Port that to another database. Seen the > > JOIN syntax? *sigh* > > Wait, I've lost something here, apparently ... but that is the case with > PostgreSQL as well: > > ams=# select ' a' = ' a'; > ?column? > ---------- > f > (1 row) > > Let me guess ... MySQL treats them as equal?? Ouch. I do not know about MySQL. Anyone else? I was referring to trailing blanks, but did not explicitly say it, though showed it in the examples. I am pretty sure that the SQL standard says that trailing whitespace is insignificant in string comparison. Rick > > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Wed, 19 Oct 2005, Richard_D_Levine@raytheon.com wrote: > I was referring to trailing blanks, but did not explicitly say it, > though showed it in the examples. I am pretty sure that the SQL > standard says that trailing whitespace is insignificant in string > comparison. Then we are broken too :) # select 'a ' = 'a '; ?column? ---------- f (1 row) ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
OK, I am not an expert on the SQL standard, but I thought the definition varied by data type e.g. varchar <> bpchar Terry Marc G. Fournier wrote: > On Wed, 19 Oct 2005, Richard_D_Levine@raytheon.com wrote: > >> I was referring to trailing blanks, but did not explicitly say it, >> though showed it in the examples. I am pretty sure that the SQL >> standard says that trailing whitespace is insignificant in string >> comparison. > > > Then we are broken too :) > > # select 'a ' = 'a '; > ?column? > ---------- > f > (1 row) > > ---- > 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 > -- Terry Fielder terry@greatgulfhomes.com Associate Director Software Development and Deployment Great Gulf Homes / Ashton Woods Homes Fax: (416) 441-9085
"Marc G. Fournier" <scrappy@postgresql.org> writes: > On Wed, 19 Oct 2005, Richard_D_Levine@raytheon.com wrote: > >> I was referring to trailing blanks, but did not explicitly say it, >> though showed it in the examples. I am pretty sure that the SQL >> standard says that trailing whitespace is insignificant in string >> comparison. > > Then we are broken too :) > > # select 'a ' = 'a '; > ?column? > ---------- > f > (1 row) # select 'a'::char(8) = 'a '::char(8); ?column? ---------- t (1 row) Trailing blanks aren't significant in fixed-length strings, so the question is whether Postgresql treats comparison of varchars right.
On Wed, 19 Oct 2005 15:40:44 -0300 (ADT) "Marc G. Fournier" <scrappy@postgresql.org> wrote: > On Wed, 19 Oct 2005, Richard_D_Levine@raytheon.com wrote: > > > I was referring to trailing blanks, but did not explicitly say it, > > though showed it in the examples. I am pretty sure that the SQL > > standard says that trailing whitespace is insignificant in string > > comparison. > > Then we are broken too :) > > # select 'a ' = 'a '; > ?column? > ---------- > f > (1 row) > > ---- Here MySQL(4.0.20-Max-log) answer. I'm not familiar with mysql but the result was your expect. -- mysql> select ' a' = ' a'; +--------------+ | ' a' = ' a' | +--------------+ | 0 | +--------------+ 1 row in set (0.00 sec) mysql> select ' a' = ' a'; +-------------+ | ' a' = ' a' | +-------------+ | 1 | +-------------+ 1 row in set (0.00 sec) mysql> select 'a ' = 'a '; +---------------+ | 'a ' = 'a ' | +---------------+ | 1 | +---------------+ 1 row in set (0.00 sec) mysql> -- ==Jun -- J.Kuwamura rC Cm ^ ~
Tom Lane <tgl@sss.pgh.pa.us> writes: > "Jim C. Nasby" <jnasby@pervasive.com> writes: >> Of course, Oracle could tank the market by offering support at >> un-competitive prices, but I can't think of a reason for them to do that >> off the top of my head. > > They might hope that they could drive the existing support companies > out of business (assuming they didn't get convicted of antitrust > violations first --- which would be an open-and-shut case, but with > the Republicans in office they probably wouldn't get prosecuted > :-(). Then they raise their rates to make lotsa money, or maybe > they'd think they could drop support at that point and the project > would die for lack of commercial support. (They seem to understand > open-source poorly enough that they might think that would happen.) It takes a lot more money to keep Oracle running than it does to run Command Prompt or Red Hat. If Oracle started offering support for PostgreSQL at rates that were low enough to be competitive with the current PostgreSQL support companies they would be cutting their own throats much faster than they would be cutting yours. Oracle requires much higher profit margins to survive than the PostgreSQL community does. Every single Oracle customer that shifted to PostgreSQL would hurt Oracle's bottom line, even if the customer opted for Oracle support. > I don't see any of this happening though. As suggested upthread, > the very *last* thing Oracle wants is to raise the visibility and > credibility of Postgres by a couple of orders of magnitude --- which > is exactly what they'd be doing by offering support for it, even if > the support was only temporary. The effects of getting the word out > would persist long afterwards. > > regards, tom lane Exactly. If Oracle promoted PostgreSQL, even momentarily, lots of Oracle customers would at least take a look, and many would like what they saw. PostgreSQL has suffered quite a bit from being in MySQL's shadow. I know lots of savvy database developers that simply assumed that PostgreSQL must be a nightmare because they took a look at MySQL (the most popular Free Software database) and were horrified. Jason
On Wed, Oct 19, 2005 at 01:02:15PM -0300, Marc G. Fournier wrote:
> >that idiocy is that a string with two blank characters is not equal to a
> >string with a single blank character in Oracle. 'a ' is not equal to 'a
> >'. 'a ' is not equal to 'a'. Port that to another database. Seen the
> >JOIN syntax? *sigh*
>
> Wait, I've lost something here, apparently ... but that is the case with
> PostgreSQL as well:
>
> ams=# select ' a' = ' a';
Well, you didn't pick the same example, because leading blanks are
significant in the char() datatype:
andrewtest=# SELECT 'a '::char='a'::char;
?column?
----------
t
(1 ligne)
But is it the case that Oracle doesn't treat that one any differently
from this:
andrewtest=# SELECT 'a'||NULL::char='a'::char;
?column?
----------
(1 ligne)
If that's the case, it's pretty odd.
A
--
Andrew Sullivan | ajs@crankycanuck.ca
When my information changes, I alter my conclusions. What do you do sir?
--attr. John Maynard Keynes
On Wed, Oct 19, 2005 at 10:07:05 -0500,
Richard_D_Levine@raytheon.com wrote:
>
> Yep. It is not just limited to empty strings; An all blank string, no
> matter the number of characters, is stored as NULL. And a corollary to
> that idiocy is that a string with two blank characters is not equal to a
> string with a single blank character in Oracle. 'a ' is not equal to 'a
> '. 'a ' is not equal to 'a'. Port that to another database. Seen the
> JOIN syntax? *sigh*
I don't believe this is true.
The following example is from Oracle 9i:
SQL> select 1 from dual where ' ' is null;
no rows selected
SQL> select 1 from dual where '' is null;
1
----------
1
Peoplesoft uses ' ' in a lot of fields as sort of a missing value code. My
theory about this is that they want to avoid database specific weirdness
involving nulls and oracles treatment of null strings.