[FoRK] [jim@netgate.com: [linux-elitists] Oracle: friend or foe?]

Stephen D. Williams < sdw at lig.net > on > Wed Feb 15 15:41:15 PST 2006

J. Andrew Rogers wrote:
> ...
>> BSD licensing, while thoughtfully protected in the case of 
>> PostgreSQL, doesn't stop Oracle (or Microsoft) from embracing and 
>> extending the open source version out of existence.
> How would that work?  PostgreSQL is not a protocol or a specification, 
> except insofar as it implements most of the broad range of ANSI SQL 
> specifications.  It is a modern MVCC engine with a mature ANSI SQL 
> implementation.  Like Oracle, SQL Server, et al, it has its own SQL 
> extensions to support a few features not specified (or poorly 
> specified) in ANSI SQL.  In the specific case of PostgreSQL, they tend 
> to bias toward Oracle-isms for non-ANSI syntax extensions, which one 
> could argue is PostgreSQL embracing and extending the Oracle database 
> environment.  Some of the PostgreSQL specific extensions are 
> compelling.  The kinds of extensions one can hack onto a database 
> engine reflect the internal transaction and concurrency control models 
> used, which in the specific case of PostgreSQL are very similar to 
> Oracle and not at all like SQL Server or MySQL.
> The "embrace and extend" model would not seem to be an applicable or 
> useful strategy here.  The market for SQL database engines is too 
> established, the PostgreSQL implementation is too mature, the OSS 
> community behind it is too well-managed, and the pace of capability 
> growth is too fast.  The only embrace and extend that would be 
> interesting is that done by a subset of the core developers (e.g. 
> GreenPlum), and in practice that has been to support implementations 
> that are not going to be allowed in the core distribution (gross hacks 
> or significant compatibility breakage) or to support features that are 
> considered too experimental to put into the main source tree but are 
> also too deeply embedded in the kernel to put in contrib.
There are many possible approaches, but let's start with this: Microsoft 
could bundle a modified PostgreSQL with WinXP, downloaded automatically, 
with proprietary extensions using both patented technology and 
leveraging other features that could be bundled.  They could make it 
.Net only, incorporate extensions that no one else could implement 
readily, etc.  They could provide free support, nice GUI tools, and free 
applications for fringe situations that wouldn't pay anyway (church 
management, high school teacher applications, etc.).

There are ways to compete with it, but only large and very popular 
projects will survive such co-opting.  GPL/LGPL and, to a lesser extent 
other licenses, prevent this.
>> There's no reason that MySQL AB couldn't incorporate any or all of 
>> PostgreSQL.
> But what would be the point?  There are some significant internal 
> architecture differences that will make it hard to support many of the 
> MySQL peculiarities on the PostgreSQL engine.  They would either have 
> to break PostgreSQL (which would not be allowed) or break some MySQL 
> compatibility.  Or fork PostgreSQL and hack it up, which is probably 
> not a good idea given their software engineering track record, 
> particularly if they want to release a product this decade.
There is a storage engine that could be separated from the SQL front-end 
and adapted as the backend of MySQL.  They could provide the PostgreSQL 
front-end at the same time just like they supported multiple back-ends 
simultaneously.  I always favored the PostgreSQL versioning storage 
mechanism anyway.  That's how I'd design a transaction database 
structure (which I did at one point).


FoRK mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://xent.com/pipermail/fork/attachments/20060215/6bf82ca2/attachment-0002.htm

More information about the FoRK mailing list