maria-developers team mailing list archive

[Sergey Vojtovich <svoj@xxxxxxxxxxx>]

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