Hi Sergei, On Fri, Mar 21, 2014 at 12:28:11PM +0100, Sergei Golubchik wrote: > Hi, Sergey! > > On Mar 21, Sergey Vojtovich wrote: > > On Tue, Mar 18, 2014 at 05:25:59PM +0100, Sergei Golubchik wrote: > > > On Mar 11, Sergey Vojtovich wrote: > > > > > > > - SHOW PROFILE is deprecated in 5.6, do we want to deprecate it too? > > > > > > I'm not sure. It's being used too, although less than INSERT DELAYED, > > > but more than XML functions :) > > > > > > Perhaps we can deprecate it in 10.1 or rewrite to use P_S... > > Ok, should I create jira task? > > Yes, please! FYI: https://mariadb.atlassian.net/browse/MDEV-5936
> > > > > - YEAR(2) is deprecated in 5.6, do we want to deprecate it too? > > > > Monty suggests that we shouldn't deprecate it. I find it Ok too. > > > > Reasons for YEAR(2) deprecation are not obvious, relevant worklog is > > > > private. Relevant revision comment says: "YEAR(2) is a subject to > > > > deprecation since it has ill design." > > > > > > 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. > > Monty likes it. Should I create jira task? > > 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: > > MariaDB [test]> create table t1 (y2 year(2), y4 year(4)); > Query OK, 0 rows affected, 1 warning (0.00 sec) > > MariaDB [test]> insert t1 values (10, 2010); > Query OK, 1 row affected (0.00 sec) > > MariaDB [test]> select * from t1; > +------+------+ > | y2 | y4 | > +------+------+ > | 10 | 2010 | > +------+------+ > 1 row in set (0.00 sec) > > MariaDB [test]> select y2 = 2010, y4=2010, y2=y4 from t1; > +-----------+---------+-------+ > | y2 = 2010 | y4=2010 | y2=y4 | > +-----------+---------+-------+ > | 1 | 1 | 1 | > +-----------+---------+-------+ > 1 row in set (0.00 sec) > > MariaDB [test]> select y2+0 = 2010, y4+0=2010, y2+0=y4+0 from t1; > +-------------+-----------+-----------+ > | y2+0 = 2010 | y4+0=2010 | y2+0=y4+0 | > +-------------+-----------+-----------+ > | 0 | 1 | 0 | > +-------------+-----------+-----------+ > 1 row in set (0.00 sec) > > Think also of Item_cache, Item_ref, GROUP BY (with temp tables), > subqueries - I really don't know in what cases YEAR(2) works and in what > it doesn't. I see. So what should we do about it? We have to different opinions. > > > > > - NO_ENGINE_SUBSTITUTION is default mode in 5.6 now, do we want it > > > > be default too? > > > > > > May be. What do you think? > > I'd say these days storage engines have way too different semantics. E.g. if > > user requests FEDERATED but gets MyISAM further queries will return > > unexpected > > results. > > > > 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_ENGIN_SUBSTITUTION and add ALLOW_ENGINE_SUBSTITUTION. 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 Regards, 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
