MDEV-29919: Support INSERT ... AS alias ON DUPLICATE KEY UPDATE #4544

MooSayed1 · 2026-01-15T10:55:14Z

MySQL 8.0.20 introduced a new syntax for INSERT ... ON DUPLICATE KEY UPDATE that allows referencing the inserted row using an alias instead of the VALUES() function:

-- Old syntax (still supported)
INSERT INTO t1 (a, b) VALUES (1, 2)
  ON DUPLICATE KEY UPDATE b = VALUES(b);

-- New syntax (this patch adds support)
INSERT INTO t1 (a, b) VALUES (1, 2) AS new
  ON DUPLICATE KEY UPDATE b = new.b;

The alias syntax is cleaner and more readable, especially when referencing multiple columns or using expressions like new.a + new.b.

Implementation

Parser: Added opt_values_row_alias rule to accept AS alias after VALUES
LEX: Added insert_values_alias field to store the alias
Name resolution: In Item_field::fix_fields(), when we're in ON DUPLICATE KEY UPDATE and the table qualifier matches the alias, we convert the reference to an Item_insert_value (equivalent to VALUES())

The traditional VALUES() function continues to work unchanged.

Tests

Added mysql-test/main/insert_update_alias.test covering:

Basic INSERT ... AS alias ON DUPLICATE KEY UPDATE
Multiple rows with alias
Expressions using alias columns (new.a + new.b)
Backward compatibility with VALUES() function
Mix of alias and table column references
INSERT without ON DUPLICATE KEY (alias ignored)
Different alias names

CLAassistant · 2026-01-15T10:55:21Z

All committers have signed the CLA.

FooBarrior

Hi @MooSayed1! Thanks for your contribution.

I think this needs a better high-level detalization. What happens if a table has a field with the same name? This is a MySQL compatibility task -- so it's important to know what MySQL does in this case.

These details on the approach to name resolution will be important to be mentioned in the commit comment.

FooBarrior · 2026-01-19T00:23:17Z

sql/item.cc

+      When we are in ON DUPLICATE KEY UPDATE and the table qualifier matches
+      the insert_values_alias, we should resolve this as VALUES(column).
+    */
+    if (select &&


No need to specify MDEV in the comments.

It's enough to have a meaningful comment.

In general, better not to refer to an exact sql_command value.

We need to make sure the syntax can't be used in the unsupposed ways, like that REPLACE...AS would fail with a syntax error, and CREATE ... VALUES would.

I'm surprised you have to check select. Why?

What does this code placement mean? it's in if (!field), meaning that it would apply only if field is not early-provided[?], but before find_field_in_tables, meaning that it would supersede a name resolution?

first thanks for the review
then
Q1, Q2, Q3: Got it, will fix all of these.

Q4: Currently the grammar allows REPLACE ... AS alias to parse (since table_value_constructor is shared), but it's ignored at runtime because duplicates != DUP_UPDATE. but i think it would be better to get a syntax error at parse time instead of silent acceptance? and maybe adding tests for these scenarios

Q5: The select check was me being cautious - ensuring we have a valid query context. It's probably redundant.

Q6: It's placed before find_field_in_tables() so the alias takes priority. If a table and alias share the same name, new.b should resolve to the alias (inserted value), not the table. This matches MySQL behavior.

and should we continue the discussion here or move to Zulip?

This matches MySQL behavior.

Please show the related MySQL output

MariaDB> SELECT VERSION(); +----------------------+ | VERSION() | +----------------------+ | 12.3.0-MariaDB-debug | +----------------------+ MariaDB> CREATE TABLE t1 (a INT PRIMARY KEY, b INT, c INT); MariaDB> INSERT INTO t1 VALUES (1, 10, 100); MariaDB> SELECT * FROM t1; +---+------+------+ | a | b | c | +---+------+------+ | 1 | 10 | 100 | +---+------+------+ MariaDB> INSERT INTO t1 VALUES (1, 20, 200) AS new ON DUPLICATE KEY UPDATE b = new.b, c = new.c; MariaDB> SELECT * FROM t1; +---+------+------+ | a | b | c | +---+------+------+ | 1 | 20 | 200 | +---+------+------+ MariaDB> INSERT INTO t1 VALUES (1, 5, 50) AS new ON DUPLICATE KEY UPDATE b = b + new.b, c = c + new.c; MariaDB> SELECT * FROM t1; +---+------+------+ | a | b | c | +---+------+------+ | 1 | 25 | 250 | +---+------+------+```

I was asking about

If a table and alias share the same name, new.b should resolve to the alias (inserted value), not the table.

oh okay mb

MySQL 8.0:

mysql> CREATE TABLE new (a INT PRIMARY KEY, b INT); mysql> INSERT INTO new VALUES (1, 999); mysql> CREATE TABLE t1 (a INT PRIMARY KEY, b INT); mysql> INSERT INTO t1 VALUES (1, 10); mysql> INSERT INTO t1 VALUES (1, 50) AS new ON DUPLICATE KEY UPDATE b = new.b; mysql> SELECT * FROM t1; +---+------+ | a | b | +---+------+ | 1 | 50 | -- Alias wins (not 999 from table) +---+------+

MariaDB the new implementation

MariaDB> -- Same test MariaDB> INSERT INTO t1 VALUES (1, 50) AS new ON DUPLICATE KEY UPDATE b = new.b; MariaDB> SELECT * FROM t1; +---+------+ | a | b | +---+------+ | 1 | 50 | -- Alias wins too Same as MySQL +---+------+

I think new couldn't be a table reference in the same request with no/different alias anyway.

Can you clarify this further?

From what I understand, my approach is incorrect when it comes to treating this as an alias. For example, consider the following case:

INSERT INTO t1 VALUES (1, 10); SELECT * FROM t1; INSERT INTO t1 VALUES (1, 50) AS t1 ON DUPLICATE KEY UPDATE b = t1.b;

In this situation, I should get a syntax error. However, with my current implementation, it continues without any issues and incorrectly treats the newly inserted row as a valid table alias.

@FooBarrior do u prefer making a new commit to fix this or u prefer doing only one commit to get the issue done?

FooBarrior

Please add test with CREATE..VALUES AS ident and REPLACE...VALUES AS ident producing a syntax error

FooBarrior · 2026-01-22T23:03:30Z

mysql-test/main/insert_update_alias.test

+);
+
+--echo #
+--echo # Test 1: Basic INSERT AS alias ON DUPLICATE KEY UPDATE


Let's remove the numbers: if we'll add some test in the middle, we'll have to renumerate everything.
Just:

--echo # Basic INSERT AS alias ON DUPLICATE KEY UPDATE

FooBarrior · 2026-01-22T23:07:25Z

sql/item.cc

+      ensures the alias takes priority over any existing table with
+      the same name, matching MySQL behavior.
+    */
+    if (thd->lex->duplicates == DUP_UPDATE &&


I think this line should be rather an assertion inside the if. If we've got to here with lex->insert_values_alias.str, then it should only be a valid case.

FooBarrior · 2026-01-22T23:11:06Z

mysql-test/main/insert_update_alias.test

+SELECT * FROM t1;
+
+--echo #
+--echo # Test 4: Backward compatibility - VALUES() function still works


No need in this one. VALUES (a) is tested even in main.insert.

FooBarrior · 2026-01-22T23:13:12Z

mysql-test/main/insert_update_alias.test

+--echo #
+--echo # Test 9: Alias takes priority over existing table with same name
+--echo #
+DROP TABLE IF EXISTS new_values;


mysql-test/main/insert_update_alias.test

FooBarrior · 2026-01-22T23:18:44Z

sql/item.cc

+      /*
+        Create a field reference without the alias qualifier,
+        then wrap it in Item_insert_value to get the inserted value (basically converting alis.column to Values(column)).
+        Use change_item_tree() for prepared statement compatibility (this's passing ps mode testing).


Remove the comment as it doesn't complement the code with any new information (or change it to do so, without stating what's written in the code).

FooBarrior · 2026-01-22T23:19:38Z

sql/sql_lex.h


  enum enum_duplicates duplicates;
+  /* Alias for INSERT ... To support the new syntax as MySQL */
+  LEX_CSTRING insert_values_alias;


Make it a Lex_ident derivative as a modern alternative.

FooBarrior · 2026-01-22T23:22:41Z

sql/sql_lex.h

  const char *clause_that_disallows_subselect;

  enum enum_duplicates duplicates;
+  /* Alias for INSERT ... To support the new syntax as MySQL */


/* Represents INSERT...VALUES as <alias> */
No need to mention MySQL "new" syntax, available yet in MySQL 8.0.19 dated year 2020 (6 years ago)

FooBarrior · 2026-01-22T23:30:26Z

sql/sql_yacc.yy

+*/
+opt_values_row_alias:
+          {
+            Lex->insert_values_alias= null_clex_str; // if AS..alias provided after Values()


remove junk (and partially false) comments

FooBarrior · 2026-01-22T23:33:14Z

mysql-test/main/insert_update_alias.test

@@ -0,0 +1,106 @@
+#
+# Test for INSERT ... VALUES (...) AS alias ON DUPLICATE KEY UPDATE syntax


I think this test can be moved to main.insert (@vuvova agree?). ODKU is also covered there.

Add MDEV and jira title with --echo #

MooSayed1 · 2026-01-23T01:00:43Z

@FooBarrior Done.

FooBarrior

Please be more careful with making changes. MariaDB is used on millions of machines, and we pay extra attention to the code quality. I hope you made that mistake just in a hurry.

FooBarrior · 2026-01-23T01:51:30Z

sql/item.cc

+        table_name.str &&
+        table_name.streq(thd->lex->insert_values_alias))
+    {
+      DBUG_ASSERT(thd->lex->insert_values_alias.str);


that's... wrong?

Just to confirm: should I remove the condition (thd->lex->duplicates == DUP_UPDATE) and instead move it into a DBUG_ASSERT inside the if block?

FooBarrior · 2026-01-23T01:52:39Z

mysql-test/main/insert_update_alias.test

+TRUNCATE TABLE t1;
+INSERT INTO t1 VALUES (1, 10, 100);
+--error ER_PARSE_ERROR
+REPLACE INTO t1 VALUES (1, 50, 500) AS new ON DUPLICATE KEY UPDATE b = new.b;


ON DUPLICATE KEY UPDATE was never possible for REPLACE, so that's out of question.

Thanks for the clarification. I realized my previous test included ON DUPLICATE KEY UPDATE with REPLACE, which caused a syntax error before even reaching the alias check.

I have updated the test to simply: REPLACE INTO t1 VALUES (...) AS new;

This should correctly verify that the alias syntax is rejected for REPLACE statements. Does this look correct to you?

FooBarrior · 2026-01-23T01:59:45Z

sql/sql_lex.h


  enum enum_duplicates duplicates;
+  /* Represents INSERT...VALUES as <alias> */
+  Lex_ident_sys_st insert_values_alias;


can you plase explain the reason to choose Lex_ident_sys_st

this's what i understand from this comment
Make it a Lex_ident derivative as a modern alternative.

when i searched i found this and i though it's the same as u mean
and it was matching what the parser's ident rule returns

MooSayed1 force-pushed the MDEV-29919-insert-as-alias branch 2 times, most recently from d724e69 to ff235ab Compare January 15, 2026 21:20

github-actions bot added the External Contribution All PRs from entities outside of MariaDB Foundation, Corporation, Codership agreements. label Jan 17, 2026

FooBarrior reviewed Jan 19, 2026

View reviewed changes

MooSayed1 force-pushed the MDEV-29919-insert-as-alias branch 2 times, most recently from 43a115c to 4dcef93 Compare January 20, 2026 22:09

FooBarrior requested changes Jan 22, 2026

View reviewed changes

MDEV-29919: Support INSERT ... AS alias ON DUPLICATE KEY UPDATE

cdc6fe5

MooSayed1 force-pushed the MDEV-29919-insert-as-alias branch from 4dcef93 to cdc6fe5 Compare January 23, 2026 00:58

FooBarrior requested changes Jan 23, 2026

View reviewed changes

FooBarrior reviewed Jan 23, 2026

View reviewed changes

		@@ -0,0 +1,106 @@
		#
		# Test for INSERT ... VALUES (...) AS alias ON DUPLICATE KEY UPDATE syntax

Uh oh!

MDEV-29919: Support INSERT ... AS alias ON DUPLICATE KEY UPDATE #4544

Are you sure you want to change the base?

MDEV-29919: Support INSERT ... AS alias ON DUPLICATE KEY UPDATE #4544

Conversation

MooSayed1 commented Jan 15, 2026

Implementation

Tests

Uh oh!

CLAassistant commented Jan 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

FooBarrior left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MooSayed1 Jan 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MooSayed1 Jan 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

FooBarrior left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MooSayed1 commented Jan 23, 2026

Uh oh!

FooBarrior left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MooSayed1 Jan 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MooSayed1 Jan 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

CLAassistant commented Jan 15, 2026 •

edited

Loading

MooSayed1 Jan 19, 2026 •

edited

Loading

MooSayed1 Jan 19, 2026 •

edited

Loading

MooSayed1 Jan 23, 2026 •

edited

Loading

MooSayed1 Jan 23, 2026 •

edited

Loading