MDEV-29919: Support INSERT ... AS alias ON DUPLICATE KEY UPDATE by MooSayed1 · Pull Request #4544 · MariaDB/server

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

+      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

+);
+
+--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

+      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

+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

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


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

+      /*
+        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


  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

  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

+*/
+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

@@ -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

+        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

+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


  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 · 2026-01-23T22:31:02Z

@FooBarrior i used this
if (Lex->sql_command == SQLCOM_REPLACE || Lex->sql_command == SQLCOM_CREATE_TABLE) {
my_yyabort_error((ER_SYNTAX_ERROR, MYF(0)));
}
to make sure that replace and create will get an error and test it
but u told me before In general, better not to refer to an exact sql_command value, so there's a better way?

FooBarrior · 2026-03-23T14:31:28Z

+          {
+            if ($1.str)
+            {
+              if (Lex->sql_command != SQLCOM_INSERT)


I actually realized that common INSERT path goes the same way as CREATE, and table_value_constructor is tied deeply into create_select_query_expression, to which insert_values basically equals, so we really cannot avoid referring to Lex->sql_command, as I was requesting before. So, I admit my incorrectness.

No problem, thanks for all the guidance along the way,I learned a lot.
Thank for reviewing too.

FooBarrior

The changes look good and complete in their functionality.

gkodinov

Hello, this is a preliminary review.
Can you please make sure that:

the buildbot tests are passing or failing in an unrelated way: currently your new test is failing on some platforms.
Your commit has a commit message as mandated by the MariaDB coding standards document.

MooSayed1 · 2026-03-24T15:08:03Z

@gkodinov For the buildbot failure — it's the case sensitivity test in insert_update_alias. The test defines alias nEw but references new.b, expecting ER_BAD_FIELD_ERROR. This works on Linux where table_alias_charset is case-sensitive, but on Windows (lower_case_table_names=1) the comparison is case-insensitive so nEw matches new and the statement succeeds instead of error.
so i was thinking about fix it by removing the case sensitivity test since alias matching follows table_alias_charset.
what do you think

gkodinov

LGTM. Let me ping Serg if he wants to review or not.

gkodinov · 2026-05-05T08:32:14Z

he does. Wait for the final review please.

Copilot

Pull request overview

Adds MySQL 8-style row-alias support for INSERT ... VALUES ... AS alias ON DUPLICATE KEY UPDATE, enabling alias.col references as a cleaner alternative to VALUES(col).

Changes:

Extends the VALUES table value constructor grammar to accept an optional alias and stores it in LEX.
Resolves alias.col in ON DUPLICATE KEY UPDATE by rewriting it to an Item_insert_value (VALUES-like) reference.
Adds MTR coverage for the new syntax and a few negative/compatibility cases.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
sql/sql_yacc.yy	Parses optional row alias after `VALUES` and stores it in `Lex->insert_values_alias`.
sql/sql_lex.h	Adds `LEX::insert_values_alias` storage.
sql/sql_lex.cc	Initializes `insert_values_alias` in `LEX::start()`.
sql/sql_insert.cc	Rejects row alias equal to target table name for DUP_UPDATE to avoid ambiguity.
sql/item.cc	Rewrites `alias.col` to `Item_insert_value` during name resolution.
mysql-test/main/insert_update_alias.test	New test coverage for alias syntax and error cases.
mysql-test/main/insert_update_alias.result	Expected output for the new test.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

vuvova · 2026-06-17T15:34:04Z

+opt_values_row_alias:
+          select_alias
+          {
+            if ($1.str)
+            {
+              if (Lex->sql_command != SQLCOM_INSERT)
+                my_yyabort_error((ER_SYNTAX_ERROR, MYF(0)));
+              Lex->insert_values_alias= Lex_ident_table($1);
+            }
+            else
+              Lex->insert_values_alias= Lex_ident_table();
+          }
+        ;


Also, consider this case

insert t1 select * from (values (1,2,3) as new) as t2 on duplicate key update b=new.c;

this works, but shouldn't. Basically detection with Lex->sql_command is incorrect.

+    /* Handle INSERT ... VALUES (...) AS alias ON DUPLICATE KEY UPDATE */
+    if (table_name.str &&
+        table_name.streq(thd->lex->insert_values_alias))
+    {
+      DBUG_ASSERT(thd->lex->duplicates == DUP_UPDATE);
+      Item_field *field_ref= new (thd->mem_root)
+        Item_field(thd, context, db_name, Lex_cstring_strlen(NULL), field_name);
+      if (!field_ref)


vuvova

forgot to change the status. see comments above.

MooSayed1 · 2026-06-18T12:44:50Z

no problem okay i'll see it.

vuvova · 2026-06-18T20:54:43Z

Thanks. I'll review. But just to set expectations — 13.1 deadline has passed, 13.2 deadline is in three months.
So I'll try to review as soon as possible, but I might need to handle issues with earlier deadlines first. For example deadline for bug fixes is in ~6 weeks, otherwise they'll miss the release.

MooSayed1 · 2026-06-18T21:32:03Z

no problem it's fully understandable take your time.
i was thinking about picking bug to resolve so yah.

Copilot

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated no new comments.

Suppressed comments (2)

sql/sql_yacc.yy:9191

The comment says the syntax is strictly ... VALUES (...) AS alias, but the rule uses select_alias which also accepts an alias without AS. Either require AS in the grammar, or update the comment to reflect the actual accepted syntax.

  Optional alias for the row(s) being inserted.
  Syntax: INSERT ... VALUES (...) AS alias
  Used to reference new values in ON DUPLICATE KEY UPDATE clause.

sql/item.cc:6490

alias.col is only converted to Item_insert_value when thd->where == THD_WHERE::UPDATE_CLAUSE. Inside subqueries within the ON DUPLICATE KEY UPDATE expression, thd->where will typically be WHERE/HAVING/etc, so the alias won’t resolve even though VALUES(col) works in those contexts. To keep the alias syntax equivalent to VALUES(), gate this conversion by "not in VALUES clause" instead of "is UPDATE_CLAUSE".

    if (thd->where == THD_WHERE::UPDATE_CLAUSE &&
        thd->lex->duplicates == DUP_UPDATE &&
        thd->lex->insert_values_alias.str &&
        table_name.str &&
        table_name.streq(thd->lex->insert_values_alias))

Implement MySQL 8.0.19 compatible row alias syntax for INSERT ... ON DUPLICATE KEY UPDATE. The alias allows referencing inserted values by name instead of VALUES(): INSERT INTO t1 VALUES (1,2) AS new ON DUPLICATE KEY UPDATE b = new.b; Parser: added opt_values_row_alias rule in sql_yacc.yy to accept AS alias after VALUES clause. The AS keyword is required and the alias must be a plain identifier, as in MySQL. The alias is accepted only when the VALUES clause is the direct value source of the INSERT, that is, when its select sits directly below the INSERT top select on the parse stack. This rejects a VALUES table value constructor used as a derived table, e.g. INSERT t1 SELECT * FROM (VALUES (1,2,3) AS new) AS t2 ON DUPLICATE KEY UPDATE b = new.c; which is a syntax error rather than silently treating new as an INSERT row alias. When no alias is present the rule leaves insert_values_alias unchanged, so a VALUES constructor in a subquery of the same INSERT does not clobber the row alias. The alias is reset once per statement in LEX::start(). LEX: added insert_values_alias to store the alias name. Name resolution: in Item_field::fix_fields(), when resolving an ON DUPLICATE KEY UPDATE value (thd->where == UPDATE_CLAUSE and duplicates == DUP_UPDATE) and the qualifier matches the row alias, the reference is converted to Item_insert_value (equivalent to VALUES()). To make this gate reliable, the ODKU update values for INSERT ... VALUES are now set up with THD_WHERE::UPDATE_CLAUSE. The alias must differ from the target table name to avoid ambiguity (ER_NONUNIQ_TABLE). Alias matching uses table_alias_charset, consistent with how table aliases are compared. The alias currently resolves only in expressions directly in the ON DUPLICATE KEY UPDATE list, not inside subqueries there; full VALUES() equivalence in subqueries is left to a follow-up task.

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

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

MooSayed1 force-pushed the MDEV-29919-insert-as-alias branch from 6e19710 to a02f27c Compare January 23, 2026 22:45

MooSayed1 requested a review from FooBarrior January 23, 2026 22:48

MooSayed1 force-pushed the MDEV-29919-insert-as-alias branch 2 times, most recently from a2dba06 to 9a0e367 Compare January 30, 2026 02:44

MooSayed1 force-pushed the MDEV-29919-insert-as-alias branch 2 times, most recently from 314e028 to 825d169 Compare February 24, 2026 04:25

MooSayed1 force-pushed the MDEV-29919-insert-as-alias branch 2 times, most recently from f809d5f to 910eabc Compare February 28, 2026 23:49

FooBarrior reviewed Mar 23, 2026

View reviewed changes

FooBarrior approved these changes Mar 23, 2026

View reviewed changes

vuvova force-pushed the MDEV-29919-insert-as-alias branch from 910eabc to c5bbf25 Compare March 23, 2026 20:19

vuvova self-requested a review March 23, 2026 20:19

gkodinov requested changes Mar 24, 2026

View reviewed changes

MooSayed1 force-pushed the MDEV-29919-insert-as-alias branch from c5bbf25 to b048f86 Compare March 24, 2026 16:43

MooSayed1 requested a review from gkodinov March 25, 2026 17:51

gkodinov approved these changes Mar 26, 2026

View reviewed changes

gkodinov assigned vuvova May 7, 2026

vuvova requested a review from Copilot June 16, 2026 20:21

Copilot started reviewing on behalf of vuvova June 16, 2026 20:21 View session

Copilot AI reviewed Jun 16, 2026

View reviewed changes

vuvova requested changes Jun 18, 2026

View reviewed changes

MooSayed1 force-pushed the MDEV-29919-insert-as-alias branch from b048f86 to eb1d7b3 Compare June 18, 2026 20:12

MooSayed1 requested a review from vuvova June 18, 2026 20:34

MooSayed1 requested a lite review from Copilot August 5, 2026 11:20

Copilot started reviewing on behalf of MooSayed1 August 5, 2026 11:21 View session

Copilot AI reviewed Aug 5, 2026

View reviewed changes

MooSayed1 force-pushed the MDEV-29919-insert-as-alias branch from eb1d7b3 to 9cf3efe Compare August 10, 2026 06:09

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

Uh oh!

Uh oh!

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!

Choose a reason for hiding this comment

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