Bug #26376 mysql_change_user() does not reset LAST_INSERT_ID()
Submitted: 14 Feb 2007 18:13 Modified: 4 Dec 2007 22:08
Reporter: Paul DuBois Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Server: C API (client library) Severity:S3 (Non-critical)
Version:5.0.36-BK, 4.1 and up OS:Linux (Linux)
Assigned to: Assigned Account CPU Architecture:Any
Tags: LAST_INSERT_ID, mysql_change_user

[14 Feb 2007 18:13] Paul DuBois
Description:
The manual says that mysql_change_user() resets the
state "as if one had done a new connect":

http://dev.mysql.com/doc/refman/5.0/en/mysql-change-user.html

However, the value of LAST_INSERT_ID() is not reset to 0.

How to repeat:
Compile the attached program, changeuser.c, and run it
as follows:

% ./changeuser test
query> DROP TABLE IF EXISTS t
0 rows affected
query> DROP TABLE IF EXISTS t;CREATE TABLE t (i SERIAL)
0 rows affected
0 rows affected
query> INSERT INTO t SET i = NULL;INSERT INTO t SET i = NULL;SELECT LAST_INSERT_ID()
1 rows affected
1 rows affected
+------------------+
| LAST_INSERT_ID() |
+------------------+
|                2 |
+------------------+
1 rows returned
query> SELECT LAST_INSERT_ID()
+------------------+
| LAST_INSERT_ID() |
+------------------+
|                2 |
+------------------+
1 rows returned

The result of that last statement should be 0.

It can be seen that other state-related information such as user
variables *are* reset as follows:

query> SELECT @x;SET @x = 1; SELECT @x
+------+
| @x   |
+------+
| NULL |
+------+
1 rows returned
0 rows affected
+------+
| @x   |
+------+
| 1    |
+------+
1 rows returned
query> SELECT @x
+------+
| @x   |
+------+
| NULL |
+------+
1 rows returned
[14 Feb 2007 18:14] Paul DuBois
changeuser.c - program to demonstrate non-reset of LAST_INSERT_ID() by mysql_change_user()

Attachment: changeuser.c (application/octet-stream, text), 8.42 KiB.

[15 Feb 2007 11:21] Valeriy Kravchuk
Thank you for a bug report. Verified just as described with 5.0.36-BK on Linux.
[4 Dec 2007 22:08] Konstantin Osipov
Duplicate of Bug#30472