Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
N/A
-
None
Description
MariaDB [test]> set statement OLD_PASSWORDS = 0 for select password('test'); |
+-------------------------------------------+ |
| password('test') | |
+-------------------------------------------+ |
| *94BDCEBE19083CE2A1F959FD02F964C7AF4CFC29 |
|
+-------------------------------------------+ |
1 row in set (0.00 sec) |
|
|
MariaDB [test]> set statement OLD_PASSWORDS = 1 for select password('test'); |
+-------------------------------------------+ |
| password('test') | |
+-------------------------------------------+ |
| *94BDCEBE19083CE2A1F959FD02F964C7AF4CFC29 |
|
+-------------------------------------------+ |
1 row in set (0.00 sec) |
MariaDB [test]> set old_passwords = 1; |
Query OK, 0 rows affected (0.00 sec) |
|
|
MariaDB [test]> select password('test'); |
+------------------+ |
| password('test') | |
+------------------+ |
| 378b243e220ca493 |
|
+------------------+ |
1 row in set (0.00 sec) |
Percona server seems to work all right.
Attachments
Issue Links
Activity
Parameters set during parsing so changing variables has no effect.
Don't set NO_SET_STMT for it, fix the following bug instead:
create table t1 (a char(10)); |
insert t1 values ('qwertyuiop'); |
prepare x from "select password(a) from t1"; |
execute x; |
set old_passwords=1; |
execute x; |
alter table t1 engine=myisam; |
execute x; |
one possible fix would be to extend the grammar to support PASSWORD(string, mode) function, and use Item_func_get_system_var as needed. Alternatively, there can be a hidden flag, not available from SQL. Like password_func_item->check_old_passwords_variable=1;
You pickup workaround to review instead of fix. Fix include decision about what function to use on fixfields call.
Subject of the e-mail is:
[Commits] b1f8911: MDEV-7015: SET STATEMENT old_passwords has no effect
20.11.14 12:45
The variable prohibited as a workaround.