[MDEV-14096] YEAR(2) has been deprecated for long time and should be removed at some point Created: 2017-10-20  Updated: 2023-11-28

Status: Stalled
Project: MariaDB Server
Component/s: Data types
Fix Version/s: 10.11

Type: Task Priority: Minor
Reporter: Elena Stepanova Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

YEAR(2) has been deprecated since at least 5.5, so 10.3 is going to be the 5th major release where it's deprecated. It was also removed in MySQL 5.7. At some point it needs to be removed in MariaDB also.



 Comments   
Comment by Ian Gilfillan [ 2020-11-09 ]

How about targeting for MariaDB 10.6? Support for YEAR(2) was removed in MySQL 5.7.5, released in 2014. MariaDB 8.0 has also deprecated support for an explicit display width: https://dev.mysql.com/doc/refman/8.0/en/year.html

Comment by Sergei Golubchik [ 2020-11-10 ]

we have one step that we can (but don't have to) do between marking deprecated and full removal. Make it look, like it's removed, but enable it back with a special value for the old_mode. And then completely remove in 10.7

Comment by Ian Gilfillan [ 2020-11-10 ]

What would making it look like it's removed actually do in the case of a YEAR(2) column?

  • YEAR(2) column definitions for new/altered tables produce an error?
  • Using YEAR(2) columns in queries produces an error?

In the MySQL process, which was quite convoluted:
From MySQL 5.6.6 ALTER TABLE as well as mysql_upgrade automatically converted to YEAR(4), and queries on YEAR(2) data were still processed.
From MySQL 5.7.5, the same applied, although queries were no longer processed.

ALTER TABLE and mysql_upgrade also automatically converted to YEAR(4)

See https://dev.mysql.com/doc/refman/5.7/en//migrating-from-year2.html and https://dev.mysql.com/doc/refman/5.6/en//migrating-from-year2.html

This allowed things to go wrong when replicating or using mysqldump.

Simply failing in 10.6 (with the option to either use the old mode setting, or altering their tables) seems neater.

Comment by Sergei Golubchik [ 2020-11-11 ]

YEAR(2) should be converted to YEAR(4) with a warning. This is how all YEAR(N) are treated:

create or replace table t1 (a YEAR(1));
Warnings:
Note	1287	'YEAR(1)' is deprecated and will be removed in a future release. Please use YEAR(4) instead
SHOW CREATE TABLE t1;
Table	Create Table
t1	CREATE TABLE `t1` (
  `a` year(4) DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1
create or replace table t1 (a YEAR(100));
Warnings:
Note	1287	'YEAR(100)' is deprecated and will be removed in a future release. Please use YEAR(4) instead
SHOW CREATE TABLE t1;
Table	Create Table
t1	CREATE TABLE `t1` (
  `a` year(4) DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1

Comment by Sergei Golubchik [ 2020-11-11 ]

In fact, I'd rather deprecate all YEAR(N) syntax, for any N. And changed SHOW CREATE TABLE to print YEAR with no width.

Comment by Daniel Black [ 2021-05-15 ]

serg, before I go too much further in validating all the test result changes, is this what you wanted? (bb-10.6-danielblack-MDEV-14096-deprecate-year-parentheses)

Comment by Daniel Black [ 2021-05-20 ]

per above - is this what you wanted? bb-10.6-danielblack-MDEV-14096-deprecate-year-parentheses

Comment by Sergei Golubchik [ 2021-05-21 ]

something along those lines. What about old_mode? Makes sense? What will you do when opening old tables with YEAR(2)? I don't think your solution handles them

Generated at Thu Feb 08 08:10:53 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.