Slashdot Mirror
MySQL 5.0.3-beta Released
Zontar The Mindless writes "MySQL Community Edition 5.0.3-beta has been released. This version has support for Stored Procedures, Triggers, Views and many other features, including a number of security enhancements and stability fixes. See the changelog for a complete listing of new features and bugfixes. MySQL 5.0.3-beta is now available in source and binary form for Linux, Solaris, MacOS X, FreeBSD, Windows, and other platforms from dev.mysql.com/downloads/ and mirror sites. RPMs for Red Hat/Fedora and SUSE Linux are also now available for the first time in the 5.0 series. This is the first Beta release in the 5.0 series, in preparation for a MySQL 5.0 production release later this year."
Don't forget that if you want to distribute it within your organisation, deploy it with your own non GPL application, or even require people to download it to use your non GPL application, you will need to get a commercial license!
The tap is on full, but the water dribbles out
Let me clarify the licensing.
First, if your application is under the GPL or another OSI compliant open source licence, you will not need a commercial licence for MySQL. MySQL AB has issued a "FLOSS Exception" which uniquely makes the GPL licence as used for MySQL compatible with OSI approved open source licences. See our website for more information.
Secondly, if you use GPL software in-house, i.e. you do not distribute, then the reciprocity requirement of the GPL does not kick in so you are free to use MySQL under GPL. (Some call the reciprocity requirement the "viral effect". I call it the reciprocity requirement, or simply the "blessing".)
The two scenarios above cover the vast majority of all cases.
If you distribute a commercially licensed application, then by the same logic that your application is commercially licensed, we think the database should be. This is the Quid pro Quo principle of MySQL AB and of a host of other open source companies.
I hope this info is useful!
Marten Mickos, CEO, MySQL AB
> I think the real question here is, are all of
> these features supported under one table type?
The use of stored routines, views, or triggers is not restricted to any one storage engine.
Il n'y a pas de Planet B.
Or should I just stick with PostgreSQL's "do it yourself" updateable views?
Using Rules/Triggers in PostgreSQL (which I guess is what you refer to with "do it yourself") to implement updatable views is actually much more powerful that "classical" updatable views, as it allows to make all kinds of views (even unions and intersections) updatable - as long as you can write a procedure that updates the involved base tables correctly for your application.
But, yes, MySQL implements updatable views in 5.0.x and for the basic testing I did it works just fine.
compares MySQL, Postgresql, DB2, Oracle, and SQLServer against the SQL Standards.
Pretty much all the other comparison pages merely have checklists claiming that something is or isn't supported. This guy actually shows the exact difference between the SQL and the non-standard ways the different vendors address their holes in the standard.