Bug #119870 meta data of year func is different between 8.0.x and 9.x
Submitted: 10 Feb 7:09 Modified: 10 Feb 8:22
Reporter: ximin liang (OCA) Email Updates:
Status: Not a Bug Impact on me:
None 
Category:MySQL Server Severity:S3 (Non-critical)
Version:9.6.0 OS:Any
Assigned to: CPU Architecture:Any

[10 Feb 7:09] ximin liang
Description:
Hello MySQL team:
  Here are some differences between 8.0.x and 9.x.

How to repeat:
Please using mysql client with --column-type-info

If execute SQL in MySQL 9.6, type is YEAR
  mysql>  select year('2026-02-10');
Field   1:  `year('2026-02-10')`
Catalog:    `def`
Database:   ``
Table:      ``
Org_table:  ``
Type:       YEAR
Collation:  binary (63)
Length:     4
Max_length: 4
Decimals:   0
Flags:      UNSIGNED BINARY NUM 

+--------------------+
| year('2026-02-10') |
+--------------------+
|               2026 |
+--------------------+

If execute in 8.0.44, type is LONGLONG 

mysql> select year('2026-02-10');
Field   1:  `year('2026-02-10')`
Catalog:    `def`
Database:   ``
Table:      ``
Org_table:  ``
Type:       LONGLONG
Collation:  binary (63)
Length:     5
Max_length: 4
Decimals:   0
Flags:      BINARY NUM 

+--------------------+
| year('2026-02-10') |
+--------------------+
|               2026 |
+--------------------+
1 row in set (0.00 sec)

Suggested fix:
In 8032, this commit https://github.com/mysql/mysql-server/commit/0a65e9d#diff-7675aa8c6082b80cc2bd88383bdd0d41... 

reverts set_data_type_year() in Item_func_year::resolve_type, but 9.6 does not merge this commit.
[10 Feb 8:22] Roy Lyseng
The original fix was reverted on 8.0, but it was a reasonable fix for later releases.
Clsoing as not a bug.