[MDEV-21558] Bug or missing documentation in UPDATE-SET behaviour Created: 2020-01-23  Updated: 2020-05-18  Resolved: 2020-05-18

Status: Closed
Project: MariaDB Server
Component/s: Data Manipulation - Update, Documentation
Affects Version/s: 10.3.21, 10.4.7
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Thomas G. Jensen Assignee: Ian Gilfillan
Resolution: Fixed Votes: 0
Labels: None
Environment:

Ubuntu



 Description   

Documentation states:

"Assignments are evaluated in left-to-right order, unless the SIMULTANEOUS_ASSIGNMENT sql_mode (available from MariaDB 10.3.5) is set, in which case the UPDATE statement evaluates all assignments simultaneously."

But it seems like the "left-to-right" evaluation is not true for multiple-table-updates. So either this is a bug or the documentation lack this information.

Example:

drop table if exists tab1;
drop table if exists tab2;
create table tab1 (c1 int, c2 int);
create table tab2 (c3 int);
insert tab1 values (1,2);
insert tab2 values (0);
 
-- first we make a multiple-table update:
 
update tab1, tab2 set c1 = c2, c2 = c1;
select * from tab1;
/* 
output:
+------+------+
| c1   | c2   |
+------+------+
|    2 |    1 |
+------+------+
 
If evalutation was left-to-right, then the result should be "2" in both columns, but it seems like this statement "evaluates all assignments simultaneously".
*/
 
-- and now a single-table update:
 
update tab1       set c1 = c2, c2 = c1;
select * from tab1;
/* output:
+------+------+
| c1   | c2   |
+------+------+
|    1 |    1 |
+------+------+
 
Here evalutation is "left-to-right".
*/



 Comments   
Comment by Elena Stepanova [ 2020-03-07 ]

It looks indeed like a documentation shortage. The MySQL manual has an explicit note about this:

Single-table UPDATE assignments are generally evaluated from left to right. For multiple-table updates, there is no guarantee that assignments are carried out in any particular order.

I don't think that MariaDB has a different logic in this regard.

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