D.1 Changes in release 5.0.0 (Development)

For the time being, version 5.0 is only available in source code. See section 2.3.4 Installing from the Development Source Tree.

The following changelog shows what has already been done in the 5.0 tree:

• Basic support for stored procedures (SQL-99 style).
• Added SELECT INTO list_of_vars, which can be of mixed, that is, global and local type.
• Deprecated the update log (no longer supported). It is fully replaced by the binary log.
• User variable names are now case insensitive: if you do SET @a=10; then SELECT @A; will now return 10. Of course, the content of the variable is still case sensitive; only the name of this variable is case insensitive.

User Comments

This is probably NOT standard SQL, but it would be an extremely handy feature for a new release. I would like to have a way to SELECT ALL TABLES for queries. This would allow building search engines a lot easier,...say for instance if you develop a website like Yahoo where each of those major categories is a new table...too many tables to write in every single table name and fields that you want to query. Just an idea.

In that scenario you would just use one table to store the information. No need for a seperate table for every category.

A very useful capability of the database is to be able to cluster a table by a particular field, for example comapny_id. This is particularly useful when a match on company_id qualifies most queries on a large table. This is a rather common situation. Since MySQL does not support such clustering a convenient work-around is to use multiple tables. I am assuming that is the reason the previous request talked about a table for each category. But rather than create non-standard SQL syntax, it would be very nice to have MySQL add 'views' to the database. The ‘union’ of all or some of the category tables would create this view. The query could then be performed on the view instead of the actual table.

It would be even better if the query engine would optimize the queries effectively so that the performance benefits could be realized. Of course this is asking a lot but if you do not ask you do not get.

What do you mean by clustering? If you mean results with that company_id are in a row you would just ORDER BY company_id. If you want to order by an additional item you can still do that. ORDER BY company_id, product_sales_totals. If by clustering you mean GROUP BY, mysql already supports that. Or maybe I'm just not aware of some SQL feature.

Another option is a merge table.

I hope select time-out is implemented in the near future.

First I'd really like to see CONNECT BY and associated functions (LEVEL, etc.). Then I'd like to see CONNECT BY,
and third, um, CONNECT BY. :-)

Getting around not having CONNECT BY is probably the #1 issue that has plagued me with MySQL. (Yeah, I can mostly get around it... but I'd prefer not to.)

InnoDB clusters on the primary key... so MySQL has it to an extent.

Add your own comment.