Username or EmailPassword
As was anticipated, time between Release Candidate 2 and 3 was nice and short, with more changes being made now to Documentation vs Code.
A current list of *known* supported platforms can be found at: http://developer.postgresql.org/supported-platforms.html
We're always looking to improve that list, so we encourage anyone that is running a platform not listed to please report on any success or failures with Release Candidate 3.
Baring *any* coding changes (documentation != code) over the next week or so, we *hope* that this will the final Release Candidate before Full Release, with that being aimed for the 15th (or earlier).
Then we could really use FOREIGN KEY ?
Yep! I've actually been using MySQL 5.0.0 alpha for a while now in Windows and I haven't experienced any instability (However, on Solaris I got some severe crashes when running some queries).
Unfortunately, I've not had much use for triggers or stored procedures, as the databases that I work on aren't nearly large enough to warrant their use.
Are views in 5.0 or is that a 5.1 thing?
so what version can we expect proper SQL92 conformance? v8?
...enterprise-level functionality such as stored procedures and triggers
"Enterprise level" my eye. These are only a couple of the most basic features that any DBMS should have. Still missing, I'm sure, are such things as CHECK constraints, DOMAINs, schemas, transaction savepoints, point-in-time recovery, and user-defined datatypes. And this still ignores MySQL's most central problem--an inconsistent approach to its own fundamental datatypes).
Maybe MySQL will move into the enterprise domain with MaxDB (SAP DB), but it sure won't with MySQL 5.0. IMHO if MySQL really wants the 'enterprise', it should leave its basic MySQL DBMS as a 'lite' system, and concentrate on MaxDB, which at least was build from the ground up on serious DBMS concepts.
Yes, views are in 5.0 (http://dev.mysql.com/doc/mysql/en/CREATE_VIEW.html), but they are limited:
A view definition is subject to the following constraints:
* The SELECT statement cannot contain a subquery in the FROM clause.
* You cannot associate a trigger with a view.
Subqueries in the FROM clause are perhaps the most useful form of subquery (essentially they are anonymous relations). And the fact that you can't associate a trigger with a view severely limits the business logic you can express with a view.