Comments on: TYPE= disappears again (MySQL 5.4.4)

By: Sheeri K. Cabral

Sheeri K. Cabral — Thu, 23 Jul 2009 14:28:25 +0000

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.”

By: Matthew Montgomery

Matthew Montgomery — Sat, 18 Jul 2009 17:43:16 +0000

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.

By: Nils

Nils — Sat, 18 Jul 2009 04:22:05 +0000

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).

By: arjen

arjen — Fri, 17 Jul 2009 22:12:30 +0000

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.

By: Tim Soderstrom

Tim Soderstrom — Fri, 17 Jul 2009 15:36:21 +0000

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.

By: Mark Callaghan

Mark Callaghan — Fri, 17 Jul 2009 13:31:55 +0000

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.

By: Justin Swanhart

Justin Swanhart — Fri, 17 Jul 2009 06:22:20 +0000

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.

By: arjen

arjen — Fri, 17 Jul 2009 06:16:06 +0000

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.

By: Antony Curtis

Antony Curtis — Fri, 17 Jul 2009 05:57:34 +0000

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.