MySQL Bugs: #14642: Please implement a CURRENT_DATABASE()/CURRENT

Bug #14642	Please implement a CURRENT_DATABASE()/CURRENT_SCHEMA() function
Submitted:	4 Nov 2005 15:01	Modified:	7 Feb 2006 21:04
Reporter:	Roland Bouman
Status:	Verified
Category:	Server: SP	Severity:	S4 (Feature request)
Version:	5.0.15-nt	OS:	Any (NA)
Assigned to:		Target Version:
Triage:	Triaged: D5 (Feature request)

Description:
When used inside a stored procedure, the builtin function DATABASE() (and it's
synonym, SCHEMA()) always returns the name of the schema in which the stored
procedure resides, even if the stored procedure's schema is not the current
database. 

It was expected that it would return the database/schema name of the current
database, e.g. the schema of the caller, not the schema of the callee.

This problem was already reported as bug 13584, wich was solved by documenting the
mentioned behaviour.

It would be nice to have an addition function, say
CURRENT_DATABASE()/CURRENT_SCHEMA(), that does return the name of the caller's
schema. 

How to repeat:
delimiter go

use test

create procedure get_schema_name()
select schema()
go

use mysql

call test.get_schema_name()
go

+----------+
| schema() |
+----------+
| test     |
+----------+
1 row in set (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Suggested fix:
Implement a function returns the name of the current database, even when called from
inside a stored procedure that resides in a database other than the current database.

I would also appreciate a function which returns the database from where the procedure is
called instead of where the procedure resides.

Thank you for a resonable feature request.

Than you Valeriy for verifying this, and thank you Markus for picking this up. It would be
nice to have many more of these reflective functions (CURRENT_PROCEDURE(),
CURRENT_TRIGGER(), CURRENT_PROCEDURE_DEFINER(), CURRENT_PROCEDURE_INVOKER...well, we
could go on and on...)  but I would have an immediate purpose for this one.

There are some more commands for stored procedures, functions etc. that unfortunately
still don't exist for triggers, e.g.

SHOW TRIGGER STATUS
SHOW CREATE TRIGGER
DROP TRIGGER IF EXISTS (doesn't work with IF EXISTS)
... maybe more?

I think that the same set of commands that are available for other features should work
for triggers, too - there also should be an own set of privileges for triggers (I think,
there is already a separate feature request for that).