MDEV-12666: CURRENT_ROLE() and DATABASE() does not work in a view

The problem lies in how CURRENT_ROLE is defined. The
Item_func_current_role inherits from Item_func_sysconst, which defines
a safe_charset_converter to be a const_charset_converter.

During view creation, if there is no role previously set, the current_role()
function returns NULL.

This is captured on item instantiation and the
const_charset_converter call subsequently returns an Item_null.
In turn, the function is replaced with Item_null and the view is
then created with an Item_null instead of Item_func_current_role.

Without this patch, the first SHOW CREATE VIEW from the testcase would
have a where clause of WHERE role_name = NULL, while the second SHOW
CREATE VIEW would show a correctly created view.

The same applies for the DATABASE function, as it can change as well.

There is an additional problem with CURRENT_ROLE() when used in a
prepared statement. During prepared statement creation we used to set
the string_value of the function to the current role as well as the
null_value flag. During execution, if CURRENT_ROLE was not null, the
null_value flag was never set to not-null during fix_fields.

Item_func_current_user however can never be NULL so it did not show this
problem in a view before. At the same time, the CURRENT_USER() can not
be changed between prepared statement execution and creation so the
implementation where the value is stored during fix_fields is
sufficient.

Note also that DATABASE() function behaves differently during prepared
statements. See bug 25843 for details or commit
7e0ad09edff587dadc3e9855fc81e1b7de8f2199

1 files changed, 49 insertions, 0 deletions

diff --git a/mysql-test/t/view.test b/mysql-test/t/view.test
index 89a8e0c9ffc..db48e1a7661 100644
--- a/mysql-test/t/view.test
+++ b/mysql-test/t/view.test
@@ -5814,6 +5814,55 @@ SELECT * FROM v1 where use_case_id = 10;
 drop view v1;
 drop table t1;
 
+--echo #
+--echo # MDEV-12666: CURRENT_ROLE() and DATABASE() does not work in a view
+--echo #
+--echo # DATABASE() fails only when the initial view creation features a NULL
+--echo # default database.
+--echo #
+--echo # CREATE, USE and DROP database so that we have no "default" database.
+--echo #
+CREATE DATABASE temporary;
+USE temporary;
+DROP DATABASE temporary;
+SELECT DATABASE();
+
+CREATE VIEW test.v_no_db AS SELECT DATABASE() = 'temporary_two';
+SHOW CREATE VIEW test.v_no_db;
+PREPARE prepared_no_database FROM "SELECT DATABASE() = 'temporary_two'";
+
+--echo #
+--echo # All statements should return NULL
+--echo #
+EXECUTE prepared_no_database;
+SELECT DATABASE() = 'temporary_two';
+SELECT * FROM test.v_no_db;
+
+CREATE DATABASE temporary_two;
+USE temporary_two;
+CREATE VIEW test.v_with_db AS SELECT DATABASE() = 'temporary_two';
+PREPARE prepared_with_database FROM "SELECT DATABASE() = 'temporary_two'";
+
+--echo #
+--echo # All statements should return 1;
+--echo #
+SELECT DATABASE() = 'temporary_two';
+SELECT * FROM test.v_no_db;
+SELECT * FROM test.v_with_db;
+EXECUTE prepared_with_database;
+
+--echo #
+--echo # Prepared statements maintain default database to be the same
+--echo # during on creation so this should return NULL still.
+--echo # See MySQL bug #25843
+--echo #
+EXECUTE prepared_no_database;
+
+DROP DATABASE temporary_two;
+DROP VIEW test.v_no_db;
+DROP VIEW test.v_with_db;
+USE test;
+
 --echo # -----------------------------------------------------------------
 --echo # -- End of 10.0 tests.
 --echo # -----------------------------------------------------------------