Bug #14642 Please implement a CURRENT_DATABASE()/CURRENT_SCHEMA() function
Submitted: 4 Nov 2005 14:01 Modified: 7 Feb 2006 20:04
Reporter: Roland Bouman Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: Stored Routines Severity:S4 (Feature request)
Version:5.0.15-nt OS:Any (NA)
Assigned to: CPU Architecture:Any
Triage: Triaged: D5 (Feature request)

[4 Nov 2005 14:01] Roland Bouman
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.
[7 Feb 2006 14:16] Markus Popp
I would also appreciate a function which returns the database from where the procedure is called instead of where the procedure resides.
[7 Feb 2006 14:21] Valeriy Kravchuk
Thank you for a resonable feature request.
[7 Feb 2006 20:04] Roland Bouman
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.
[7 Feb 2006 21:43] Markus Popp
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).