TYPO3 Core

Yes, it's a waste of bytes. But it saves a lot of trouble, because we don't have to worry about checking the size and the possible unsigned attribute - which has to be taken in to account. Otherwise inserting 168 into a tinyint equivalent might fail, because it isn't unsigned on databases other than MySQL and therefore ranges from -127...+127

This simplified handling of integer (and other types) sizes was deliberately chosen and I have to intention to fix it. If someone comes up with a patch that reliably saves enough bytes to warrant a change, feel free to attach it here and reopen the bug...

Simple solution: drop TYPO3 support for unsigned ints. Either plainly remove this option from the SQL definition or silently increase to the next int byte size. I cannot image that many extensions really need unsigned ints and Mysql is the only DB that has this datatype.

Other solution is that DBAL gets the unsigned info (from the SQL parsers) and does the byte size increase for itself.

[Why can't I add a note to this resolved issue, but apparently Martin could? Duh.]

It is not about needing unsigned ints, signed ints do no harm. But a tinyint signed holds 127 max, whereas unsigned holds 256 max. Simply removing unsigned and staying with the size equivalent of tinyint breaks the DB.

So the unsigned attribute is dropped, that is why we need to enlarge the size. And we simply enlarge to the maximum, to be sure it fits. Because ADOdb maps metatypes to different sizes in different RDBMS, depending on the "relative range" for that DB, if you get what I mean and IIRC. :)