TYPE= disappears again (MySQL 5.4.4)

I like the 5.4 developments, overall. It has useful stuff and is being developed and released a reasonable pace. Good progress. While perusing the MySQL 5.4.4 changelog, one particular change drew my attention, since it’s been (re)appearing since 2006. It’s the removal of the TYPE= keyword which was obsoleted since MySQL 4.1 in favour of the ENGINE= syntax in CREATE/ALTER TABLE.

While on the surface it may seem ok to remove the obsolete keyword, there are quite a few apps out there that use it, and that cannot be changed. So these will now be unable to use MySQL 5.4 or beyond. I filed this as a bug in 2006, MySQL bug#17501. If you’re interested in the “history of reappearance”, take a peek at the comments and their timeline. I just put in a new comment to note the 5.4.4 change.

I suppose that a new developer comes along and reckon that removing this keyword is a good idea. But really, why do we need to remove one keyword from the parser? Because that’s all it is. And removing it really does break apps.
Let’s not. Again. Please! And this time please put a comment in the parser source files, referring to the bug#, so that it doesn’t get recycled at a later date. Please just leave it in.

9 Responses to “TYPE= disappears again (MySQL 5.4.4)”

  1. I guess I am guilty of deprecating the TYPE attribute. It has been deprecated for quite a long time now. Personally, I am okay with TYPE but I think during the 2003 MySQL developer meeting in Bordeaux, France, it was decided that “Storage Engine” was how they would be called.
    IMO, it would have been simpler to add STORAGE as an optional keyword before TYPE.
    I don’t think I was the first to remove it per-se… I think it was someone who was following through with removing it as the deprecation warning originally promised.

  2. Ye that “followup” removal has been done at various times, hence the bugreport. This just history repeating for the Nth time.
    The original TYPE -> ENGINE was actually a marketing decision, as I understand. Which is perfectly fine. I don’t tell anybody to use the TYPE keyword.
    The only issue I have is removal of the old TYPE keyword. It can just stay.

  3. While I am happy that things like the replication command line options are being removed, TYPE should still raise a warning when used, IMHO.

    There is no use case for removing the TYPE keyword. It would be like removing the AS keyword, because it is optional. It doesn’t hurt to use TYPE, and TYPE isn’t used anywhere else in the server as a keyword.

    I know an argument can be made for reducing the number of keywords, but in this case, I too think it deserves to stay.

  4. This also removes SHOW MUTEX STATUS and SHOW INNODB STATUS and it will take me a few days to remember to use the new versions of those commands.

    I prefer that changes like this are not done. I doubt this makes the parser any faster.

    On the bright side they have recently fixed a batch of bugs we filed for replication that makes it a bit more stable after a crash.

  5. TYPE today, int(#) tomorrow. MySQL is a living, breathing, application and I like that idea that MySQL is removing things that should no longer be there. If the thing doesn’t do anything, remove it and avoid confusion and even possibly bugs in the future.

    For the legacy applications that use this, they can stay on their current version of MySQL without issue.

    Otherwise, MySQL risks becoming too much like Windows. I’m not wanting to start an OS war here, but Microsoft is invested so heavily in backwards compatibility that it makes innovation difficult. I don’t know if its true or not, but someone once told me that Microsoft actually coded an special chunk of code to address memory handling issues in SimCity into Windows itself just so people who wanted to play SimCity could. That’s crazy to me. As great a game as it is, if SimCity did not follow the API properly, it should be punished.

    A similar story holds true here. Part of the reason, I think, MySQL is having so many issues, is due to looking backwards, not forwards. And, instead of complaining when they are trying to start heading in the right direction, I think we should praise it.

  6. Tim, I appreciate what you’re saying, but this is not about legacy code. This is a particular case about a keyword in the parser.
    Removing it has no practical purpose or benefit.

  7. If it’s there it also needs to stay documented and tested with every release. I’m in favor of removing it. As long as source for old mysql releases is provided it won’t break legacy applications (which should break anyways if they go beyond basic SQL).

  8. I agree that ENGINE= is the best way to go, TYPE= is a bit ambiguous. I’m happy to see it go away.

    @acurtis
    STORAGE as a keyword to define the table engine is not an option because it is already used in the CREATE/ALTER TABLE syntax to designate where records in NDB should be held STORAGE MEMORY vs STORAGE DISK.

    Bikesheding and on a tangent here a bit but… I think it would be a nice feature for other engines to allow creation globally shared temporary tables by using STORAGE MEMORY/DISK instead of always using ENGINE=MEMORY for those.

  9. As much as I agree with you – backwards compatibility is a good thing – I also have to note that TYPE has been deprecated since MySQL 4.0, according to the documentation, and it’s clearly listed in the CREATE TABLE documentation for 5.1 and 3.x and 4.x (but not 5.0, sadly):

    http://dev.mysql.com/doc/refman/5.1/en/create-table.html
    http://dev.mysql.com/doc/refman/4.1/en/create-table.html states “ENGINE was added in MySQL 4.0.18 (for 4.0) and 4.1.2 (for 4.1).” and then notes that TYPE is deprecated

    4.0.18 came out in February 2004. Isn’t 5 years long enough for a developer to change a silly word? If not, what *else* is wrong with the software? (I hate it when software gives me spurious warnings.) Let’s take for example InnoDB Hot Backup, which *still* in 2009 used TYPE internally. Ridiculous, especially given how expensive it is.

    So, yeah — on the one hand “backwards compatibility is good, especially when it’s not a big deal to keep it.” On the other hand — “update your damn software within 5 years.”

Leave a Comment