Hi, Sergey! On Mar 24, Sergey Vojtovich wrote:
- YEAR(2) is deprecated in 5.6, do we want to deprecate it too? I'd deprecate it - I agree about "ill design", it has lots of gotchas that are literally impossible to fix. In some cases it seems to work, but it's enough to change the query slightly - and it won't. OTOH it requires less storage, which is a pro. It looks well-defined, that is 0-69 are 2000-2069 and 70-99 are 1970-1999. Though I can't judge the design. The fundamental design flaw - only the Field itself knows that it's YEAR(2), no item knows it. So, as long as you use YEAR(2) in any expression - it loses its magic powers:
I see. So what should we do about it? We have to different opinions.
Monty said that the reason for introducing YEAR(2) was to use less storage. I don't know if that's a valid argument today, but anyway. The suggestion was to remove YEAR(2) and introduce YEAR1 (or TINYYEAR, or keep YEAR(2), whatever) type. Which stores the year in one byte, as the old YEAR(2). But Field converts it to 4-digit year on retrieval - in all val_xxx methods. That is, SELECT will show it as 4-digit year, even though it'll be stored only in one byte. If we do it this way, new one-byte year field will have no magic behavior and it'll reliably work in all cases.
- NO_ENGINE_SUBSTITUTION is default mode in 5.6 now, do we want it be default too? I believe it is a good idea to make it default too. Okay. Old idea of SQL_MODE always was that empty set is always the default. I mean, all sql-mode values were selected this way (e.g. NO_ENGINE_SUBSTITUTION vs. ALLOW_ENGINE_SUBSTITUTION).
But I agree, we cannot keep this forever... Hmm... we could probably keep this idea, change the meaning of empty set to implicitely include NO_ENGINE_SUBSTITUTION and add ALLOW_ENGINE_SUBSTITUTION.
Yes, Monty suggested that too. I'm not sure it's a good idea, it basically turns NO_ENGINE_SUBSTITUTION into a no-op. No matter whether it's set or not, engine substitution is not allowed. Which is backward incompatible and will break applications that rely on the engine substitution (e.g. replication with transactional master and non-transactional slaves).
As for the new defaults it came to be that they are well documented, so I won't have to dig the code: http://dev.mysql.com/doc/refman/5.6/en/server-default-changes.html
all changes of buffer sizes, etc are ok. options that affect the behavior... I don't know if we can do it that late, even though it's a compatibility with MySQL 5.6 fix. Regards, Sergei