Hi Sergei, On Mon, Mar 24, 2014 at 10:13:05AM +0100, Sergei Golubchik wrote: > 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. Ok, then I assume this issue is known and doesn't need extra attention from my side yet.
> > > > > > > - 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). I see. > > > 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. Ok, I'll create a task then. Thanks, Sergey _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
