[MDEV-22210] ERROR 1054 Unknown column 'ID' in 'field list' exists on 10.4, but doesn't exist on 10.3 Created: 2020-04-10  Updated: 2020-05-18  Resolved: 2020-05-18

Status: Closed
Project: MariaDB Server
Component/s: Stored routines
Affects Version/s: 10.3.22, 10.4.12
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Alena Subotina Assignee: Elena Stepanova
Resolution: Not a Bug Votes: 0
Labels: need_feedback

Attachments: File Script.sql     PNG File screenshot-1.png     PNG File screenshot-2.png    

 Description   

Preconditions: MariaDB 10.4.12 is installed from your package without any additional server changes.
Only information_schema, mysql and performance_schema are available after installation. No user databases are present.
All actions are performed with the root user.
Steps to reproduce:
1. Run the command line and execute the command:
"C:\Program Files\MariaDB 10.4\bin\mysql.exe" -u root -p root
2. Execute the script (see attachment) with the command: source D:/Script.sql
Actual result:
ERROR 1054 (42S22) at line 40 in file: 'D:\Script.sql': Unknown column 'ID' in 'field list'

Expected result:
If we do the same steps on MariaDB10.3.22, this script is successfully completed.

 Comments   
Comment by Elena Stepanova [ 2020-04-13 ]

The error seems to be correct though, isn't it? ID indeed isn't defined in the function/package, and the statement it's used in doesn't refer to any table.

The simplified example is this:

CREATE FUNCTION f() RETURNS INT RETURN ID;

In 10.4, it throws an error upon function creation:

10.4 edc3899d97

 
MariaDB [test]> CREATE FUNCTION f() RETURNS INT RETURN ID;
 
ERROR 1054 (42S22): Unknown column 'ID' in 'field list'

but in 10.3 it only throws the error upon function call:

10.3 811e4409c

 
MariaDB [test]> CREATE FUNCTION f() RETURNS INT RETURN ID;
 
Query OK, 0 rows affected (0.024 sec)
 
 
 
MariaDB [test]> SELECT f();
 
ERROR 1054 (42S22): Unknown column 'ID' in 'order clause'

The difference was introduced in 10.4.0. We could find what exactly caused it, there was extensive refactoring in parser and around it, but I'm not sure it makes much sense. The behavior in 10.4 seems to be correct, so there is nothing to fix; but the difference is not critical enough to backport the change to 10.3.

Generated at Thu Feb 08 09:13:02 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.