mariadb-dump current-user guard compares incompatible account representations and cannot fire

The current-user protection predicate used by mariadb-dump --system=users --replace compares CURRENT_USER() with a quoted SQL account expression. On MariaDB 12.3.3, these representations differ, so the predicate intended to protect the current import account evaluates to false.

This occurs when mariadb-dump --system=users --replace emits the guard intended to protect the current import account.

Decisive observation

The following query reproduces the values compared by the emitted guard for the current account. It creates no persistent objects.

SELECT CURRENT_USER() AS current_identity,

       CONCAT(QUOTE(User), '@', QUOTE(Host)) AS dump_account_expression,

       CURRENT_USER() = CONCAT(QUOTE(User), '@', QUOTE(Host)) AS emitted_guard_fires,

       CURRENT_USER() = CONCAT(User, '@', Host) AS canonical_guard_fires

FROM mysql.user

WHERE CONCAT(User, '@', Host) = CURRENT_USER();

The recorded result was:

current_identity  dump_account_expression  emitted_guard_fires  canonical_guard_fires

root@%             'root'@'%'                0                    1

Semantic mismatch

CURRENT_USER() returns the canonical identity root@%, whereas concatenating QUOTE(User), '@', and QUOTE(Host) produces the display expression 'root'@'%'. Comparing those strings returns 0 even though the row represents the current account. The control comparison without the embedded SQL quotes returns 1.

For the mysql.user row matching CURRENT_USER(), the protection predicate should evaluate to 1. Because it evaluates to 0, it cannot identify and protect the current import account before the generated DROP USER operation.